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dependent  on  the  operation  of  database  management  systems 
based  on  one  of  the  three  generally  known  data  models 
(i.e.,  network,  hierarchical,  or  relational)  for  the 
centralized  control  of  operational  data.  As  an  alternative 
to  the  development  of  separate,  stand-alone  systems  for 
specific  models,  recent  research  has  proposed  a  system 
designed  to  support  multiple  data  models  and  model-based 
languages  as  if  the  system  is  a  heterogeneous  collection  of 
database  systems.  This  proposal  is  based  on  the  existence 
of  a  simple  and  powerful  data  model  to  which  the  three  well- 
known  models  can  be  mapped.  This  model,  the  attribute-based 
data  model,  is  the  data  model  upon  which  the  tiui  t  i  -Backend 
Database  System  (MDBS) ,  a  software  database  machine,  is 
based.  This  thesis  concentrates  on  the  language  interface 
aspects  of  i mpl em en t i ng  MDBS  as  a  kernel  for  the  support  of 
relational  databases.  In  particular,  this  thesis  provides 
the  design  and  analysis  of  an  interface  between  the 
relational  query  language  (SQL)  and  the  attribute-based  data 
language  (ABDL). 
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I.    INTRODUCTION 

Database  technology  is  rapidly  becoming  an  extremely 
important  aspect  o-f  data  processing.  Commercial  database 
management  systems  have  only  been  available  since  the 
1960's.  Today,  many  thousands  o-f  organizations  (e.g., 
corporations,  universities,  governments)  are  critically 
dependent  on  the  efficient  and  reliable  operation  of  these 
systems.  Each  of  these  organizations  has  invested  large 
amounts  of  time,  energy,  and  money  to  ensure  that  the 
various  end  users  a.re  provided  the  data  they  need  for  doing 
their  jobs  as  effectively  and  efficiently  as  possible.  Any 
of  the  three  generally  known  approaches  to  the  design  of 
database  systems  (i.e.,  network,  hierarchical,  and 
relational)  provides  for  the  centralized  control  of  an 
organization's  operational  data.  However,  questions 
concerning  the  ease  of  understanding,  use,  and 
implementation  have  stimulated  research  to  determine  the 
"best"  approach.  The  earliest  database  systems  were  based 
on  the  network  or  the  hierarchical  model.  These  models  lend 
themselves  well  to  the  efficient  implementation  necessary 
for  the  maintenance  of  large  databases.  Today,  with  the 
increased  emphasis  on  the  ease  of  use  and  understanding, 
many  of  the  newer  commercialized  systems  are  based  on  the 
relational   model.      Examples   of   commercially    available 
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sy-tems  based  on  these  models  include:  IMS  (hierarchical), 
SQL/DS  (relational),  and  IDMS  (network).  Each  o-f  these 
systems  utilizes  a  model— based  data  language  which  allows 
the  user  to  specify  the  operations  to  be  performed  on  the 
data. 

Once  a  commitment  is  made  to  manage  a  large  database 
containing  an  organization's  operational  data  through  the 
implementation  o-f  one  o-f  these  systems,  it  is  -financially 
prohibitive  to  change  to  another  approach.  In  addition  to 
the  obvious  re-programming  requirement,  user  personnel 
(including  high— level  executive  users)  must  be  re— trained  in 
the  syntax  and  semantics  of  a  different  data  language. 
Demur j i an ,  et .  al . ,  have  proposed  an  attractive  alternative 
to  the  development  of  separate,  stand— alone  systems  for 
specific  models.  Their  research,  reported  in  ERef .  ID, 
proposes  that  a  system  can  be  designed  "...to  support 
multiple  data  models  and  model— based  languages  as  if  the 
system  is  a  heterogeneous  collection  of  database  systems. " 

The  above  proposal  is  based  on  the  existence  of  a  simple 
and  powerful  data  model  to  which  the  network,  hierarchical, 
and  relational  models  can  be  mapped.  This  is  the  attribute- 
based  data  model  as  originally  described  by  Hsiao  CRef.  2D 
and  extended  by  Wong  CRef.  3D.  This  is  the  data  model  of 
the  Mul ti-backend  Database  System  (MDBS),  a  software 
database  system  designed  by  Menon  and  Hsiao  LRef .  4D. 
The  proposal  of  [Ref.    ID  is  that  the  attri bute— based  system 
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(MDBS),  with  the  attribute-based  data  model  and  the 
attribute-based  data  language  (ABDL) ,  can  serve  as  a  kernel 
for  the  support  of  several  data  models  and  the  data 
languages  based  on  those  models. 

The  attribute-based  system  is  ideally  suited  to  its 
proposed  role  as  a  kernel  of  database  systems.  As 
demonstrated  by  Banerjee  CRefs.  5,  6,  and  73,  a  relational, 
hierarchical,  or  network  database  can  be  converted  into  an 
attribute-based  database.  The  primary  database  and 
aggregate  operations,  RETRIEVE,  INSERT,  DELETE,  UPDATE,  MIN, 
MAX,  SUM,  COUNT,  and  AVG  Are  supported  by  the  system's  high- 
level  data  language,  ABDL.  Finally,  language  inter-faces  can 
be  developed  to  translate  relational,  hierarchical,  or 
network  data  language  constructs  into  ABDL  constructs.  In 
this  thesis,  we  s.re  concerned  with  the  language  inter-face 
aspects  of  this  research. 

In  particular,  this  thesis  provides  the  design  and 
analysis  of  a  relational  interface  to  the  attribute-based 
system  (MDBS).  We  extend  the  work  of  Macy  CRef.  83,  who  has 
shown  that  a  subset  of  the  relational  model— based  data 
language,  SOL  (Structured  Query  Language)  can  be  directly 
supported  by  MDBS  and  ABDL.  Macy  has  provided  mappings  from 
the  SOL  SELECT,  INSERT,  DELETE,  and  UPDATE  constructs  to  the 
corresponding  ABDL  constructs:  RETRIEVE,  INSERT,  DELETE, 
and  UPDATE.  The  translations  a.re  limited  to  gueries 
involving  simple,   si ngl e— rel at i on  operations.    Using  these 
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basic  mappings  as  a  -foundation,  we  show  that  SQL  queries 
involving  set  membership  operations  can  also  be  mapped 
directly  to  ABDL  constructs.  We  also  demonstrate  that  other 
SQL  constructs  (o-f  particular  importance,  the  nested  SQL 
SELECT)  can  be  mapped  to  a  series  of  ABDL  operations. 
Finally,  we  propose  a  so-ftware  structure  to  -facilitate  the 
implementation  o-f  a  complete  relational  inter-face  for  the 
attri bute— based  kernel  (i.e.,  MDBS).  In  the  following  two 
sections,  we  discuss  our  design  goals  and  our  unconventional 
approach  to  the  design  of  the  SQL  interface.  In  the  last 
section  of  this  chapter,  the  organization  of  the  thesis  is 
presented . 

A.   DESIGN  GOALS 

We  Ars  motivated  to  design  a  SQL  interface  to  MDBS  in 
order  to  demonstrate  the  feasibility  of  utilizing  the 
attri bute— based  system  as  the  kernel  of  database  systems  in 
general.  However,  our  intention  is  not  to  propose  changes 
to  MDBS  itself.  Instead,  we  propose  that  the  SQL  interface 
be  implemented  on  the  host  computer.  All  translations  sre 
accomplished  in  the  SQL  interface.  MDBS  continues  to 
receive  and  process  requests  written  in  the  syntax  of   ABDL. 

Related  to  the  goal  of  avoiding  modifications  to  the 
functionality  of  MDBS  is  the  goal  of  keeping  the  syntax  of 
ABDL  intact.  We  utilize  existing  ABDL  constructs  in  our 
query  translations.  A  single  SQL  query  may  map  to  one  ABDL 
request  or  a  series  of  ABDL  requests.   The  processing  of  one 
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request  may  depend  on  the  results  of  some  other  request  in 
the  series.  Clearly,  the  inter-face  must  include  some  method 
of  controlling  the  iterative  processing  o-f  series  of 
requests.  The  software  structure  of  our  proposed  interface 
(described  in  Chapter  VI  and  augmented  in  Chapter  VII) 
provides  for  this  iterative  control. 

As  discussed  above,  we  have  made  it  our  goal  to  leave 
MDBS  and  ABDL  unchanged.  We  also  desire  to  make  our 
interface  transparent  to  the  SQL  user.  For  example,  in  a 
corporate  environment,  a  new  employee  with  previous 
experience  with  SQL/DS  should  be  able  to  log  in  at  a  system 
terminal,  input  a  SQL  request,  and  receive  result  data  in  a 
relational  format  (i.e.,  a  table).  The  employee  requires  no 
training  in  MDBS  or  ABDL  procedures  prior  to  utilizing  the 
system.  An  obvious  advantage  is  that  the  new  employee 
becomes  a  contributing  member  of  the  organization  almost 
immediately,  with  no  retraining.  The  non— product 1 ve  period 
of  new  employee  indoctrination  is  greatly  reduced. 

B.   APPROACH  TO  DESIGN 

Our  approach  to  the  design  and  analysis  of  a  SQL 
interface  to  MDBS  is  unconventional  by  today's  standards. 
The  normal  method  is  to  design  a  system  in  a  top— down 
manner.  High— level  abstractions  are  considered  first,  while 
deferring  lower— level  details.  In  this  thesis,  we  consider 
the  lowest  levels  first.  We  are  building  upon  the  basic 
subset  of  SQL-to-ABDL   mappings  provided   by  Macy  CRef.   81. 
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As    additional    SQL   operations  are  incorporated    into 

the  inter-face,  we  make  appropriate  additions  to  the  set  o-f 
SQL-to-ABDL  mappings.  The  -functional  requirements  of  an 
overall  software  structure  for  the  interface  become  apparent 
in  Chapter  V ,  when  we  present  ABDL  translations  for  the 
nested  SQL  SELECT.  The  functionality  and  organization  of 
structure  components  is  described  graphically,  in  text,  and 
through  the  presentation  of  high— level  algorithms.  We 
reiterate  that,  in  the  development  of  the  SQL  interface, 
MDBS  is  considered  to  be  a  "black  box"  which  processes 
database  requests  presented  in  the  syntax  of  ABDL.  We  are 
proposing  an  interface,  residing  on  a  host  computer,  which 
enables  a  user  to  access  a  relational  database  implemented 
on  an  attri bute— based  system.  Recommendations  for 
modification  within  the  structure  of  MDBS  are  made  only  if  a 
desirable  SQL  operation  cannot  be  supported  by  existing  ABDL 
operat i  ons. 

Our  approach  to  the  presentation  of  SQL— to— ABDL  mappings 
is  as  follows.  We  first  review  the  direct  mappings  (i.e., 
SELECT/RETRIEVE,  INSERT/ INSERT ,  DELETE/DELETE,  and 
UPDATE/UPDATE)  developed  by  Macy  CRef.  8D.  Beginning  in 
Chapter  IV,  we  investigate  additional  operations  to  be 
supported  by  the  interface.  The  functionality  of  each  of 
these  operations  is  thoroughly  explained  through  the  use  of 
example  queries.  The  equivalent  ABDL  requests  are  then 
determi  ned . 
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All   examples  on  database  operations  presented  in   this 

thesis    are       based   on   the   Suppl  i  ers— and— Parts  database 
depicted   in  Date  ERef  .   9D.    This  database  contains   three 

relations:     "S"    (Suppliers),   "SP"    (Shipments),  and   "P" 

(Parts).    We   use  many  of  Date's  examples  directly  because 

they     are          well— known,     thereby    -facilitating  reader 

understanding  o-f  our  SQL  to  ABDL  translations.   The  database 
is  depicted  in  Figure  1. 

C.   ORGANIZATION  OF  THE  THESIS 

In  Chapter  II,  we  present  an  overview  of  the 
organization  and  functionality  of  the  Mul t i — backend  Database 
System  (MDBS).  Also  presented  are  descriptions  of  the 
attribute— based  data  language  (ABDL)  and  the  relational  data 
language  (SQL).  Chapter  III  reviews  the  direct  SQL— to- 
ABDL  mappings  as  developed  by  Macy  ERef.  83.  SQL  set 
membership  operations  involving  single  relations,  and  the 
equivalent  ABDL  requests  are  explained  in  Chapter  IV. 
Chapter  V  explains  set  membership  operations  on  multiple 
relations  (i.e.,  nested  SELECT).  In  Chapter  VI,  a  software 
structure  is  proposed  to  facilitate  the  implementation  of 
nested  SELECTS.  In  Chapter  VII,  the  interface  software 
structure  is  modified  to  include  the  functionality  necessary 
to  accomplish  the  translation  of  other  si ngl e— rel at i on  and 
mul t i pi e— rel at i on  operations.  Chapter  VIII  presents  our 
conclusions  and  recommendations  for  future  research. 
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II.   THE  MULT I -BACKEND  DATABASE  SYSTEM  (MDBS) ,  ITS  DATA 
LANGUAGE  (ABDL)  AND  THE  INTERFACE  LANGUAGE  (SQL) 


As  we  begin  our  investigation  into  the  -feasibility  of 
designing  and  implementing  a  complete  relational  interface 
-for  the  Mul  ti-backend  Database  System  (MDBS),  it  is 
important  to  gain  a  general  -familiarity  with  the 
organisation  of  MDBS  and  with  the  system's  attribute-based 
data  language  (ABDL).  We  have  selected  the  Structured  Query 
Language  (SQL)  as  the  relational  data  language  to  be 
supported  by  our  interface.  Therefore,  we  must  also  have  an 
understanding  of  the  structure  and  capabilities  of  this 
1 anguage. 

In  Sections  A  and  B,  we  briefly  describe  MDBS  and  ABDL, 
respectively.  Section  C  provides  a  brief  description  of 
SQL.  These  descriptions,  though  somewhat  superficial, 
should  enable  the  reader  to  comfortably  follow  subsequent 
discussions.  A  complete  description  of  MDBS  and  ABDL  can  be 
found  in  Hsiao  CRefs.  4  and  103 .  The  reader  is  referred  to 
Astrahan  CRef.  113  and  Chamberlin  CRef.  12D  for  in— depth 
discussions  of  SQL. 

A.   A  REVIEW  OF  THE  MULT I -BACKEND  DATABASE  SYSTEM  (MDBS) 

MDBS  is  a  mul ti pi e— mi ni computer  backend  database 
computer.  Off-the-shelf  hardware  and  specialized  software 
^re       combined   to  provide  database  management  service   to   a 
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host  computer.  Figure  2  depicts  the  hardware  organization 
o-f  MDBS.  The  hardware  organization  includes  one 
minicomputer  as  a  controller  and  multiple  minicomputers  as 
backends.  Each  backend  has  one  or  more  dedicated  disk 
drives.  The  controller  and  the  backends  are  connected  by  a 
broadcast  bus.  The  database  is  distributed  across  the  disk, 
drives  o-f  the  backend  in  such  a  manner  that  the  backends  can 
process  requests  in  parallel,  providing  a  significant 
performance  advantage  over  traditional  si ngl e— processor 
archi  tectures. 

The  prototype  MDBS,  currently  operating  at  the  U.S. 
Naval  Postgraduate  School,  uses  a  VAX  11/780  as  the 
controller  and  two  PDP  11 /44s  as  the  backends.  Each  of 
these  backends  has  one  or  more  disk  drives  for  its  dedicated 
use.  The  multiple  backends  and  the  controller  a.re  connected 
by  DEC's  Parallel  Communication  Links  (PCLs).  Their 
broadcast  capabilities  a<re    simulated  in  software. 

The  major  design  goal  of  MDBS  is  to  provide  a  high- 
performance  system  for  large-capacity  databases.  Throughput 
improvement  should  be  proportional  to  the  number  of 
backends,  and  the  response— ti me  reduction  should  be 
inversely  proportional  to  the  number  of  backends.  A  second 
design  goal  is  that  the  system  should  be  easily  extensible. 
The  system  should  be  able  to  accomodate  additional  backends 
with  no  modification  to  existing  software,  and  no  new 
programming.      The   incorporation   of   additional   backends 
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Figure  2.   The  MDBS  Hardware  Organization 


should  not  require  modification  to  existing  hardware,  and 
disruption  o-f  system  activity  should  be  minimal.  The 
software  structure  of  MDBS  provides  this  extensibility.  The 
software  of  the  backends  is  identical,  utilizing  identical 
operating  software  for  the  additional  backends. 

It  is  clear  that  the  controller  could  become  a 
bottleneck.  MDBS  reduces  this  potential  by  minimizing  the 
role  of  the  controller  and  maximizing  the  amount  of  work 
done  by  the  backends.  The  software  structure  of  MDBS  is 
shown  in  Figure  3.  The  functions  of  the  controller  are 
limited  to  request  preparation,  insert  information 
generation,  and  post  processing.  The  request  preparat 1  on 
f  uncti  ons  are  performed  before  a  request  is  placed  on  the 
broadcast  bus.  These  functions  handle  parsing,  syntax 
checking,  and  the  transformation  of  a  parsed  request  into 
the  form  required  for  processing  at  the  backends.  The 
i  nsert  i  nf ormat i  on  qener at i  on  f uncti  ons  are  performed  during 
the  processing  of  an  insert  request.  These  functions 
provide  additional  information  to  the  backends,  such  as  the 
identity  of  the  particular  backend  at  which  the  record  is  to 
be  inserted.  The  post  processi  nq  f  uncti  ons  are  performed 
after  replies  are  returned  from  the  backends.  For  example, 
result  data  are  collected  prior  to  forwarding  to  the  host 
computer . 

As  described  above,  the  controller  does  relatively 
little   work.    The   backends,    on   the   other   hand,    are 
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responsible  -for  all  the  major  database  management  -Functions. 
These  are  directory  management,  record  processing,  and 
concurrency  control .  The  di  rectory  management  f uncti ons 
determine  the  secondary  storage  addresses  o-f  the  appropriate 
records  and  perform  directory  table  maintenance.  The  record 
processi  nq  -f  uncti  ons  store  records  into  secondary  storage, 
retrieve  records  from  secondary  storage,  and  select  the 
records  that  contain  the  desired  information.  The 
concurrency  control  f uncti  ons  ensure  consistency  for 
concurrent  execution  of  user  requests. 

The  key  to  hi gh— per f ormance  is  in  the  parallelism  of  the 
backends.  The  database  is  distributed  across  the  disks  of 
all  of  the  backends.  Therefore,  when  a  request  is 
broadcasted  from  the  controller,  each  backend  can  execute 
the  request  on  its  portion  of  the  database.  To  yield  an 
additional  performance  advantage,  a  queue  of  requests  is 
maintained  at  each  backend.  Each  backend  schedules  requests 
for  execution  independent  of  the  activities  of  the  other 
backends. 

B.   THE  ATTRIBUTE-BASED  DATA  LANGUAGE  (ABDL) 

We  preface  our  discussion  of  the  syntax  and 
functionality  of  ABDL  with  a  brief  introduction  to  the  data 
model  supported  by  MDBS.  This  model  is  the  attribute-based 
data  model,  originally  developed  by  Hsiao  CRef.  2D-  The 
fallowing  constructs  are  informally  defined.  A  database 
consists   of  a  collection  of  files.    Each  file   contains   a 
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unique  group  of  records.  Each  record  is  composed  o-f  two 
parts.  The  -first  of  these  parts  is  a  collection  of 
attr i  bute— val ue  pai  rs  or  keywords.  An  attribute-value  pair 
is  an  element  of  the  Cartesian  product  of  the  attribute  name 
and  the  domain  of  attribute  values.  As  an  example, 
<STATUS,30>  is  an  attr i bute— val ue  pair  having  30  as  the 
value  for  the  STATUS  attribute.  In  each  record,  there  is  at 
most  one  attr i bute— val ue  pair  for  each  distinct  attribute 
defined  in  the  database.  The  last  part  of  each  record 
contains  textual  information.  This  is  the  record  body.  An 
example  of  a  record  without  a  record  body  is  shown  below. 
We  note  that  all  examples  in  this  and  subsequent  sections 
are  based   on   Date's   suppl i ers-and-parts    database    as 

described  in  CRef  93  and  in  Chapter  I. 

(  < F I LE , S  > , <  S# , S 1 > , < SNAME , Smi  th  > , <  STATUS , 20  > , <  C I T Y , London  >  ) 

The  tirst  attr i bute— val ue  pair  in  every  record  indicates  the 
file  name.  In  the  example  above,  the  file  name  is  'S'  (the 
Suppliers  file). 

The  database  can  be  accessed  through  the  use  of  keyword 
predicates.  Each  of  these  keyword  predicates  is  a  three- 
tuple  of  the  form  (attribute,  rel at i onal _oper ator ,  value) , 
e.g. ,  (STATUS  <  30).  When  keyword  predicates  are  combined 
into  a  conjunction  such  as 

((FILE  =  S)  A   (STATUS  <  30)) 
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or  into  a  disjunction  of  conjunctions  such  as 

(((FILE  =  S)  A   (SNAME  =  Smith))   V 
((FILE  =  S)  A   (SNAME  =  Jones))) 

a  query  (in  disjunctive  normal  -form)  o-f  the  database  is 
formed . 

In  the  -following  subsections,  we  will  see  how  these 
keyword  predicates  and  queries  are  used  in  the  attribute- 
based  data  language  for  search  and  retrieval  operations.  We 
describe  the  syntax  and  functionality  of  the  four  types  of 
request  supported  by  ABDL:  retrieve,  insert,  delete,  and 
update.  Appendix  A  provides  a  formal  specification  of  this 
non— procedural  language. 

1.   The  RETRIEVE  Request 

The  RETRIEVE  request  allows  the  user  to  query  the 
database  for  information.  This  operation  obtains  the 
requested  data  without  altering  the  database.  The  syntax 
i  s: 

RETRIEVE  (Query)  <Target-l i st >  CBY  attribute]  [WITH  Pointer] 

The  type  of  the  request  is  indicated  by  the  reserved  word 
RETRIEVE.  As  we  have  seen,  the  Query  part  is  composed  of 
predicates  in  the  disjunctive  normal  form.  From  our 
previous  discussion,  we  note  that  the  Query  specifies  the 
file  and  those  records  within  the  file  which  satisfy  the 
request.      The   attributes   for   which   values  are       to   be 
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extracted  -from  this  portion  o-f  the  database  are  contained  in 
the  Target-list.  ABDL  supports  five  aggregate  operations: 
AVG,  COUNT,  MAX,  MIN,  and  SUM.  There-fore,  the  attribute 
value  may  be  an  aggregate  of  values  from  multiple  records, 
or  the  value  from  a  single  record. 

The  BY  and  WITH  clauses  sre  optional,  as  indicated 
by  the  square  brackets  in  the  syntax.  The  BY— clause  is  used 
when  a  grouping  by  some  attribute  is  desired.  The  WITH- 
clause  specifies  whether  pointers  to  the  retrieved  records 
must  be  returned  to  the  user  for  later  use  in  an  update 
request.  As  an  example  of  a  RETRIEVE  request,  if  we  wish  to 
obtain  supplier  names  for  all  of  the  suppliers  with  STATUS 
greater  than  10,  grouped  by  location,  we  may  use  the 
following  query: 

RETRIEVE  ((FILE  =  S)  A   (STATUS  >  10))  <SNAME>  BY  CITY 

2.   The  INSERT  Request 

The  INSERT  request  alters  the  database  by  adding  a 
new  record.   The  syntax  is: 

INSERT  Record 

An  example  of  an  INSERT  request  is: 

INSERT  (  <FILE,S>,  <S#,S1>,  <SNAME , Smi th >  ) 

This  adds  a  record  to  the  suppliers  file  for  supplier  number 
SI  and  identifies  that  supplier  as  Smith. 


3.  The  DELETE  Request 

The  DELETE  request  alters  the  database  by  removing 
an  existing  record  or  records.   The  syntax  is: 

DELETE  Query 
where   Query  specifies  which  records  are    to  be  deleted.    An 
example  o-f  a  DELETE  request  is: 

DELETE  ((FILE  =  S)  A   (STATUS  =  10)) 

This  deletes  all  records  in  the  suppliers  -file  -for  suppliers 
whose  status  is  equal  to  10. 

4.  The  UPDATE  Request 

The  UPDATE  request  alters  the  database  by  modifying 
the  value  of  some  attribute  in  an  existing  record.  The 
syntax  is: 

UPDATE  Query  Modifier 

where  Modifier  indicates  which  of  five  types  of  modification 
is  to  be  performed.  These  modifiers  are  defined  as  follows. 
A  type-0  modi  f  i  er  sets  the  new  value  of  the  attribute  being 
modified  to  a  constant.  A  type— I  modi  f i er  sets  the  new 
value  of  the  attribute  to  be  some  function  of  its  old  value 
in  the  record  being  modified.  A  type— I  I  modi  f  i  er  sets  the 
new  value  to  be  some  function  of  another  attribute  value  in 
the  record  being  modified.  A  type— III  modi  f  i  er  sets  the  new 
value  to  be  some  function  of  another  attribute  value  in 
another  record  identified  by  the  Query  in  the   modifier.    A 
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type  IV  modi  f  i  er  sets  the  new  value  to  be  some  function   of 

another  attribute  value  in  another  record  identified  by  the 

pointer  in  the   modifier.   An   example  of  an  UPDATE  request 

(using  a  type-I  modifier)  is: 

UPDATE  (FILE  =  S)  < STATUS  =  STATUS  +  10 > 

which  adds  10  to  the  status  of  all  suppliers. 

C.   THE   RELATIONAL   QUERY   LANGUAGE  (SQL)  AS  THE   INTERFACE 
LANGUAGE 

AS  indicated  in  Chapter  I,  we  have  selected  the 
Structured  Query  Language  (SQL)  as  the  data  language  to  be 
supported  by  our  relational  interface  to  the  Mul ti -backend 
Database  System  (MDBS).  The  language's  commercial 
availability  coupled  with  its  simple  yet  powerful 
functionality  make  SQL  an  ideal  choice. 

In  the  preceding  section,  we  described  the  attribute- 
based  data  model  prior  to  introducing  ABDL.  However,  in 
this  section,  we  assume  a  certain  familiarity  with  the 
relational  data  model  as  we  prepare  to  describe  the  four 
basic  constructs  of  SQL:  SELECT,  INSERT,  DELETE,  and 
UPDATE.  If  the  reader  desires  a  review  of  relational 
theory,  there  sre  several  very  good  texts  available.  In 
particular,  we  recommend  Date  CRef.  9D  and  Ul 1  man  [Ref  .  13D. 
A  discussion  of  the  mapping  between  the  relational  data 
.model  and  the  attribute-based  data  model  can  be  found  in 
Banerjee  CRef.  63. 


1  .   The  SELECT  Query 

Data  retrieval,  which  is  represented  syntactically 
as  a  SELECT-FROM— WHERE  block,  is  the  most  basic  operation  of 
SQL.  Mapping  indicates  that  a  known  quantity  (STATUS  =  30) 
is  to  be  trans-formed  into  a  desired  quantity  (SNAME)  by 
means  o-f  a  relation  (S).  The  attributes  to  be  returned  aire 
listed  in  the  SELECT  clause  (the  built-in  functions  COUNT, 
SUM,  AVG,  MAX,  and  MIN  may  be  applied  to  these  attributes). 
The  FROM  clause  indicates  which  relation  or  relations  are  to 
be  searched.  The  WHERE  clause  specifies  the  retrieval 
conditions,  As  an  example,  i  f  we  desire  to  obtain  the  names 
o-f  suppliers  whose  status  is  30,  we  may  use  the  -following 
query: 

SELECT    SNAME 

FROM      S 

WHERE     STATUS  =  30 

The  SELECT  construct  allows  the  user  great 
-flexibility  in  data  retrieval  operations.  The  user  can  list 
several  relations  in  the  FROM  clause  in  order  to  obtain 
values  selected  from  more  than  one  relation  (JOIN 
operations).  The  WHERE  clause  can  contain  any  number  of 
predicates  including  the  six  standard  relational  operators 
(  =  ,  "*=,  >,  >= ,  <,  and  <  =  )  ,  and  the  Boolean  operators  (AND, 
OR,  and  NOT).  Parenthesis  may  be  used  to  indicate  a  desired 
order  of  evaluation.    The  set  comparison  operators  IN,  ANY, 
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and  ALL  may  also  be  used  in  the  WHERE  clause.  (We 
investigate  the  use  of  these  operators  in  Chapter  IV.) 

There  a.re  many  other  possible  variations  to  the 
SELECT  operation  including  the  extremely  useful  nested 
SELECT.  In  the  nested  SELECT,  the  result  o-f  one  SELECT 
request  is  used  in  the  WHERE  clause  o-f  another  SELECT 
request.  (The  nested  SELECT  is  thoroughly  described  in 
chapter  V. ) 

2.   The  INSERT  Query 

The  INSERT  request  allows  the  user  to  insert  a  new 
tuple  (row)  or  set  o-f  tuples  into  an  existing  relation 
(table).  Insertion  o-f  a  single  tuple  can  be  accomplished 
through  the  use  o-f  a  query  such  as 

INSERT  INTO  S: 

<  '  S6  '  ,  '  Rol 1 i  ns ' ,  ' 40 '  ,  ' Newport ' > 

In  this  example,  all  o-f  the  attributes  a.re  present  and  in 
the  correct  order.  I-f  some  attribute  values  are  unknown, 
those  attributes  for  which  values  are  being  inserted  must  be 
listed  following  the  relation  name.  A  SQL  INSERT  statement 
may  also  evaluate  a  SELECT  request  and  insert  the  resulting 
set  of  tuples  into  an  existing  (or  temporary)  relation.  An 
example  of  such  an  INSERT  operation  is  as  follows. 
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INSERT  INTO  TEMP: 

SELECT  P# 
FROM  SP 
WHERE     S#  =  'S2' 

This  enters  into  TEMP  part  numbers  -for  all  parts  supplied  by 
suppl i  er  S2. 

3.  The  DELETE  Query 

The  DELETE  specifies  tuples  to  be  removed  -from  the 
database.  The  tuples  ^re  indicated  by  means  o-f  a  WHERE 
clause  that  is  syntactically  identical  to  the  WHERE  clause 
o-f  a  SELECT  construct.  As  an  example,  to  delete  supplier 
number  -five  -from  the  supplier  relation,  we  may  use  the 
following  query. 

DELETE    S 

WHERE     S#  =  'S5' 

We  may  also  delete  all  shipments  with  the  query 

DELETE    SP 

The  SP  relation  is  still  known,  but  it  is  now  empty. 

4.  The  UPDATE  Query 

The  UPDATE  request  is  syntactically  similar  to  the 
DELETE  request,  except  that  a  SET  clause  is  used  to  specify 
the  updates  to  be  made  to  the  selected  tuples.  New 
attribute  values  contained  in  the  SET  clause  may  be  stated 
as  constants,   as  expressions  based  on  the  original  value  of 


the   attribute,   or   as  nested  queries.    An  example   o-f   an 
UPDATE  request  is 

UPDATE  S 

SET  STATUS  =  2  *  STATUS 

WHERE  CITY  =  'London' 

This  doubles  the  status  of  all  suppliers  in  London. 
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III.   REV I EN  OF  BASIC  MAPPINGS 

As  we  have  described  in  Chapter  II,  the  -four  primary 
database  operations  of  the  Structured  Query  Language  (SQL) 
are  SELECT,  INSERT,  DELETE,  and  UPDATE.  Macy  CRef.  8]  has 
shown  that  for  a  subset  of  simple,  single-relation  SQL 
queries  of  all  four  types,  there  exist  direct  mappings  into 
requests  of  the  Attribute-based  Data  Language  (ABDL).  These 
mappings    are  fundamental   to   all   further    SQL— to— ABDL 

translations  introduced  in  this  thesis.  Therefore,  in  the 
remainder  of  this  chapter,  we  provide  a  review  of  these 
basic  mappings  as  defined  by  Macy.  We  explain  the  mappings 
both  graphically  and  in  text.  Each  graphical  presentation 
will  display  the  general  forms  of  the  SQL  and  ABDL 
constructs,  and  the  mappings  between  them  (such  as  Figure  4, 
which  depicts  the  SELECT  to  RETRIEVE  mapping).  Sample 
translations,  utilizing  our  suppl i er s— and— par ts  database, 
will  be  presented  in  the  text.  The  subset  of  SQL,  for  which 
translations  are  described,  contains  those  operations  that 
Macy  has  determined  can  be  directly  supported  by  MDBS  and 
ABDL.  In  the  next  chapter,  we  will  show  that  SELECT 
requests  involving  set  comparison  operators  can  also  be 
directly  supported.  In  subsequent  chapters,  we  describe 
translations  for  SQL  constructs  such  as  the  nested  SELECT 
which  involve  multiple  ABDL  constructs. 
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Prior  to  describing  the  specific  SQL  to  ABDL  mappings 
(e.g.,  SELECT  to  RETRIEVE),  we  discuss  two  general  types  of 
mapping  identified  by  Macy:  Syntact i c— substi tution  mapping 
and  Conversion  mapping.  Syntacti  c-subst i tuti  on  mappings  are 
accomplished  by  simple  substitution  of  syntactical  terms. 
Mappings  requiring  only  substitution  are  denoted  by  a 
directional  arrets  labeled  with  a  square  containing  the 
letter  S  (e.g. ,  the  mapping  between  the  reserved  words 
SELECT  and  RETRIEVE  in  Figure  4).  Conversi  on  mappi  nqs  are 
accomplished  by  combining  a  clause  from  an  SQL  query  with 
information  about  the  ABDL  data  structure  to  create  the 
equivalent  clause  of  the  ABDL  construct.  Mappings  requiring 
conversion  are  denoted  by  a  directional  arrow  labeled  with  a 
triangle  containing  the  letter  C  (e.g.,  the  mapping  between 
the  SQL  FROM  and  WHERE  clauses  to  the  ABDL  Query  in  Figure 
4).  We  will  describe  conversion  mappings  in  more  detail  as 
we  present  each  for  the  SQL  to  ABDL  translations.  For  an 
extensive  discussion  of  the  basic  mappings  described  in  this 
chapter,  the  reader  is  referred  to  Macy  CRef.  83. 

A.   MAPPING  THE  SQL  SELECT  QUERY  TO  THE 
ABDL  RETRIEVE  REQUEST 

The   mappxng  from  the  SQL  SELECT  to  the  ABDL  RETRIEVE  is 

depicted  in  Figure  4.   The   mapping   proceeds   as   follows. 

The  reserved  word  SELECT  is  mapped  by  syntactic  substitution 

to   the   reserved   word  RETRIEVE.    The   sel _expr_l l st   maps 

directly   to   the   target_list.    A   conversion   mapping   is 
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required  to  translate  the  FROM  and  WHERE  clauses  to  the  ABDL 
query  clause,  This  is  accomplished  by  creating  an  equality 
keyword— predi  cate  -for  the  rel  at  i  on_name ,  e.g.  ,  FILE  = 
rei ati on_name.    This   new   predicate  is  combined   with   the 


SELECT 

sel _expr_l  i  st 

FROM  Rel at i on_name 

WHERE  boolean: 

C GROUP  BY  -field  name! 


s 


V 

RETRIEVE 


V 

target_l i  st 


[BY  attribute: 
Figure  4.   Mapping  the  SQL  SELECT  to  the  ABDL  RETRIEVE 

other  predicates  listed  in  the  boolean  expression  to  -form  an 
equivalent  ABDL  query  clause.  This  conversion  is  called  a 
query-conver si  on  mappi  nq.  The  GROUP  BY  construct  maps 
directly  to  the  BY  construct.  As  an  example  o-f  a  SELECT  to 
RETRIEVE  translation,  the  -following  SQL  SELECT  will,  -for 
each  part  supplied,  get  the  part  number  and  the  total 
quantity  supplied  o-f  that  part. 
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SELECT     P#,SUM(QTY) 
FROM       SP 
GROUP  BY   P# 

An  equivalent  ABDL  request  is 

RETRIEVE  (FILE  =  SP)  <P# , SUM (QTY) >  BY  P# 

B.   MAPPING  THE  SQL  INSERT  QUERY  TO  THE  ABDL  INSERT  REQUEST 

The  mapping  -from  the  SQL  INSERT  to  the  ABDL  INSERT  is 
depicted  in  Figure  5.  The  mapping  proceeds  as  -follows.  The 
reserved  word  INSERT  is  the  same  -for  both  requests.  A 
conversion  mapping,  referred  to  as  a  record— conver si  on 
mappi  nq ,  in  this  case,  is  required  to  translate  "INTO 
rel ati on_name  insert_spec"  into  the  ABDL  "record".  As  we 
have  seen  in  Chapter  II,  the  ABDL  record  is  a  series  o-f 
attri  bute— val  ue  pairs,  the  -first  pair  of  which  identifies 
the  file  name.   This  mapping,  then,  can  be   accomplished   by 

INSERT 

INTO  rel at i on_name 

-i  nsert_spec 


a 


INSERT 

record 
Figure  5.   Mapping  the  SQL  INSERT  to  the  ABDL  INSERT 

constructing  attri bute— val ue  pairs  for  the  relation/file  and 
relation/file  name   and   for   the  values  of   the   attributes 


listed  in  the  insert_spec.  As  an  example  of  an  SQL  INSERT 
to  ABDL  INSERT  translation,  the  -following  SQL  INSERT  query 
will  add  part  P7  (name  'Washer',  color  'Grey',  weight  '2', 
city  'Athens')  to  rel  at  i  on/-f  i  1  e  P. 

INSERT  INTO  P: 

< ' P7 ' , ' Washer " , ' Grey ' , '  2  '  , ' Athens ' > 

An  equivalent  ABDL  request  is 

I NSERT  ( < F I LE , P > , < P# , P7  > , <  PNAME , Washer  > , 

< COLOR , Gr  ey  > , < WE I GHT , 2  > , <  C I TY , At h  en  s  > ) 

C.   MAPPING  THE  SQL  DELETE  QUERY  TO  THE  ABDL  DELETE  REQUEST 

The  mapping  from  the  SQL  DELETE  to  the  ABDL  DELETE  is 
depicted  in  Figure  6  The  mapping  proceeds  as  follows.  The 
reserved  word  DELETE  is  the  same  for  both  requests. 
The  query— conver si  on  mapping,    as   described   in  Section  A, 

DELETE 


S 


relation  name 


DELETE 


[WHERE  boolean: 


query 
Figure  6.   Mapping  the  SQL  DELETE  to  the  ABDL  DELETE 

is   used   to  translate  "rel at i on_name"  and   "WHERE   boolean" 
into  the  ABDL  query  clause.    As  an  example  of  an  SQL  DELETE 
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to  ABDL  DELETE  translation,   the  following  SQL  DELETE   query 
will  delete  supplier  SI  -from  the  suppliers  relation. 

DELETE   S 

WHERE    S#  ='S1 ' 

An  equivalent  ABDL  request  is 

DELETE  ( (FILE  =  S)  A   (S#  =  Sl>) 

D.   MAPPING  THE  SQL  UPDATE  QUERY  TO  THE  ABDL  UPDATE  REQUEST 
The   mapping  from  the  SQL  UPDATE  to  the  ABDL   UPDATE   is 
depicted  in  Figure  7.   The  mapping  proceeds  as   follows. 


UPDATE 


relation  name 


s 


v 

UPDATE 


set  clause  list 


C WHERE  boolean] 


query 


modi  f  i  er 


Figure  7.   Mapping  the  SQL  UPDATE  to  the  ABDL  UPDATE 

The  reserved  word  UPDATE  is  the  same  in  both  requests.  As 
in  Sections  A  and  C,  the  query— conversi on  mapping  is  used  to 
translate  "rel ati on_name"  and  "WHERE  boolean"  into  the  ABDL 
query  clause.  This  conversion  is  common  to  the 
SELECT/RETRIEVE,    DELETE,   and   UPDATE   translations.    The 
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component  "set_cl ause_l i st "  directly  correlates  to  the  ABDL 
"modi  -f  i  er  "  ,  i.e.  ,  both  constructs  specify  how  the  records 
being  modified  are  to  be  updated.  To  accomplish  this 
translation,  the  modifier  conversion  mappi  nq  is  used. 
The  conversion  required  is  a  restructuring  of  SQL 
set_cl ause_l i st  constructs  into  acceptable  ABDL  format.  The 
modi f i er— conver si  on  is  similar  to  the  query— conversi on.  We 
now  present  an  example  of  the  conversions  that  are  required 
in  the  translation  of  an  SQL  UPDATE  to  an  ABDL  UPDATE.  If 
we  desire  to  double  the  status  of  all  suppliers  in  1 ondon , 
we  may  use  the  following  SQL  query: 

UPDATE   S 

SET       STATUS  =  2  *  STATUS 

WHERE    CITY  =  'London' 

An  equivalent  ABDL  request  is 

UPDATE  ((FILE  =  S)  A   (CITY  =  London))   (STATUS  =  2  *  STATUS) 
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IV.  SELECTIONS  WITH  SET  MEMBERSHIP  OPERATIONS  ON 
SINGLE  RELATIONS 

As  we  have  seen,  the  condition  -following  the  WHERE 
clause  in  SQL  SELECT  operations  may  include  the  normal 
comparison  operators,  i.e.,  =,  '""= ,  etc.  Macy  CRef.  8]  has 
shown  that  MDBS  supports  simple,  single-relation  retrieval 
operations  using  these  comparison  operators.  SQL  allows  the 
use  o-f  several  additional  comparison  operators.  Three  of 
these,  IN,  ANY,  and  ALL,  deal  with  the  set  membership,  and 
&r&  of  particular  interest  to  us  as  we  investigate  possible 
extensions  to  the  subset  o-f  SQL  operations  whose  inter-faces 
were  proposed  by  Macy. 

In  this  chapter  we  show  how  qualifications  using  IN, 
ANY,  and  ALL  can  be  supported  by  MDBS.  We  first  consider 
the  simple  case  where  set  members  are  enumerated  in  the 
query.  Some  o-f  the  examples  we  provide  herein  may  not 
appear  very  useful.  However,  they  will  serve  to  illustrate 
the  mechanics  of  SELECT  operations  using  these  comparison 
operators.  Their  usefulness  will  become  apparent  in  Chapter 
V,  when  we  use  them  in  retrievals  involving  multiple  levels 
of  nesting. 

In  sections  A,  B,  and  C,  we  formally  define  the 
comparison  operators  IN,  ANY,  and  ALL,  respectively.  As 
noted  by  Cha'mberlin,  et .  al  .  CRef.  143,  English  language 
definitions  of  these  operators  are,        at  best,  ambiguous.   We 
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shall,  nevertheless,  attempt  to  explain  them  in  text  prior 
to  providing  a  clarifying  definition  in  predicate  logic.  An 
example  of  a  SELECT  query  will  then  be  given  for  each  case. 
The  result  relation  of  each  of  these  examples  will  be 
provided  in  order  to  further  clarify  the  uses  of  these 
operators.  As  in  previous  chapters,  our  examples  specify 
retrievals  of  data  contained  in  Date's  database  (defined  in 
Chapter  I).  UJe  will  continue  to  utilize  this  database 
throughout  this  thesis.  Again,  note  that  some  of  our 
examples  =^rB  taken  directly  from  Date  CRef .  9D.  In  Sections 
D,  E,  and  F  we  express  IN,  ANY,  and  ALL  in  the  ABDL 
requests. 

A.    IN-MEMBERSHIP  OPERATIONS 

The  comparison  operator,  IN,  can  be  thought  of  as  the 
set  membership  operator,  c  .  Correspondingly,  NOT  IN  is 
equivalent  to  %  . 

1 .   The  Set  Member shi p  Operator ,  ' IN ' 

The  operator,  IN,  is  evaluated  as  follows.  The 
condition,  A  IN  B,  evaluates  to  be  true  if  and  only  if  the 
value  of  attribute  A  is  equal  to  at  least  one  value  in  the 
enumerated  set  B.  The  formal  definition  in  predicate  logic 
foil ows: 


Vx    (x  E  a  <==>   2]y    <Y  E  B 


x  =  v)  ) 
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EXAMPLE   1: 


I-f  we  wish  to  obtain  supplier  numbers  tor 
suppliers  Smith  and  Jones,  we  may  use  the 
■following  query: 

SELECT    S#,SNAME 

FROM      S 

WHERE     SNAME  IN  (Smi th , Jones) 


The  result  relation  is; 


s# 

SNAME 

si 

S2 

Smi  th 
Jones 

2.   The  Set  Membership  Operator ,  ' NOT  I N  ' 

The  operator,  NOT_IN,  is  evaluated  as  -follows.  The 
condition,  A  NOT_IN  B ,  evaluates  to  be  true  i-f  and  only  i-f 
the  value  o-f  attribute  A  is  not  equal  to  any  value  in  the 
enumerated  set  B.  The  -formal  de-finition  in  predicate  logic 
-foil  ows: 


Vx  <:<  E  A  <==>Vy  (y  6  B  J  x  ~=  y)  ) 


EXAMPLE   2:   I-f   we  wish  to   obtain   supplier   numbers   for 
suppliers   who  supply   some  parts,   but  do   not 

supply  parts  P3  or    P4 ,  we  may  use  the  -following 
query: 

SELECT  S# 

FROM  SP 

WHERE  P#  NOT  IN  (P3,P4) 
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the  result  relation  is: 


S# 


S2 
S3 


B.   ANY-MEMBERSHIP  OPERATIONS 

The  comparison  operator,  ANY,  is  used  in  conjunction 
with  the  six  standard  relational  operators,  =,  "**=,  <  =  ,  >= , 
<,  and  >.  It  specifies  variations  on  the  theme  of  set 
membership  as  explained  in  the  following  subsections. 

1-   The  Set  Membershi  p  Operator ,  ' =ANY ' 

The  operator,  =ANY ,  is  interchangeable  with  the 
operator,  IN.  The  condition,  A  =ANY  B,  evaluates  to  be  true 
if  and  only  if  the  value  of  attribute  A  is  equal  to  at  least 
one  value  in  the  enumerated  set  B.  Example  1  and  the 
predicate  logic  definition  given  for  the  operator  IN  apply 
equally  to  =ANY.  In  subsequent  examples  involving  set 
membership,  we  shall  use  IN  rather  than  =ANY. 

2.   The  Set  Membershi  p  Operator  ,  '  "J=ANY  ' 

The  operator,  "J=ANY ,  is  evaluated  as  follows.  The 
condition,  A  ~=ANY  B,  evaluates  to  be  true  if  and  only  if 
the  value  of  attribute  A  is  not  equal  to  at  least  one  value 
in  the  enumerated  set  B.  The  formal  definition  in  predicate 
1 ogi  c  foil ows: 


Vx  (x  £  A  <==>  ^Y  (V   £  B  I  *  "  = 


y)> 


EXAMPLE   3:    If   we   wish  to   obtain   supplier   numbers   for 
suppliers   who   supply  some  parts,   but  do   not 
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supply   both   parts  PI  and  P2 ,   we  may  use   the 
following  query: 

SELECT  S# 
FROM  SP 
WHERE     P#  "-=ANY  (P1,P2) 


The  result  relation  is: 


S# 


S3 

S4 


3.   The  Set  Member shi  p  Operator ,  ' <  =ANY ' 

The  operator,  <=ANY,  is  evaluated  as  -fallows.  The 
condition,  A  <=ANY  B,  evaluates  to  be  true  if  and  only  if 
the  value  of  attribute  A  is  less  than  or  equal  to  at  least 
one  value  in  the  enumerated  set  B.  This  implies  that  the 
value  of  attribute  A  is  less  than  or  equal  to  the  max  1  mum 
value  in  the  set  B.  <=ANY,  then,  is  not  particularly  useful 
in  the  case  of  enumerated  sets.  The  operators  >= ,  >,  and  < 
a.re  similarity  of  limited  value  when  sets  are  enumerated  in 
the  query.  As  previously  stated,  the  usefulness  of  these 
operators  will  become  apparent  when  we  discuss  queries  in 
which  the  results  of  one  SELECT  operation  determine  the  set 
members  in  the  WHERE  clause  of  another  SELECT  operation 
(nested  SELECT).  The  formal  predicate  logic  definition  of  A 
<=ANY  B  follows: 

Vx  ( x  6  A  <  ==  >  ]]  y  ( y  6  B  |  x  <  =  y )  )  ==  > 
V>;  (x  6  A  <==>  x  <=  max  {B> ) 
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As  can  be  seen  -from  the  predicate  logic  de-f  inition,  when 
using  the  operator,  <=ANY,  it  is  logically  unnecessary  to 
list  more  than  one  value  (the  maximum  value)  in  the 
enumerated  set  B.  A  similar  comment  is  applicable  when 
using  >=ANY ,  <ANY,  ar  >ANY.  However,  in  anticipation  o-f  our 
nested  SELECT  discussion  in  Chapter  V,  example  queries 
utilizing  these  operators  will  each  contain  an  enumerated 
set  having  more  than  one  member.  The  additional  values 
listed  in  the  set  sre  superfluous.  However,  they  will  help 
demonstrate  the  differing  results  obtained  through  the  use 
of  the  ANY  and  ALL  operators. 

EXAMPLE  4:  If  we  wish  to  obtain  supplier  names  for 
suppliers  whose  status  is  not  larger  than  30, 
we  may  use  the   following  query: 

SELECT    SNAME 

FROM      S 

WHERE     STATUS  <  = ANY  (10, 20 , 30 ) 


The  result  relation  is: 


SNAME 


Smi  th 
Jones 
Blake 
Clark 
Adams 


4.   The  Set  Member shi  p  Operator ,  ' >=ANY ' 

The  operator  >=ANY  is  evaluated   as    follows.    The 
condition   A   >=ANY  B  evaluates  to  true  if  and  only   if   the 
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value  of  attribute  A  is  greater  than  or  equal  to  at  least 
one  value  in  the  enumerated  set  B.  This  implies  that  the 
value  o-f  attribute  A  is  greater  than  or  equal  to  the  minimum 
value  in  the  set  B.  The  -formal  definition  in  predicate 
loaic  -follows: 


V><   (-<  €  a  <==>  ^v  (y  £  B 


>  =  y>>  == 


V>'   (x  E  A  <==> 


>=  min  <!B]  ) 


EXAMPLE  5:  If  we  wish  to  get  supplier  names  for  suppliers 
whose  status  is  not  less  than  10,  we  may  use 
the  following  query: 


SELECT    SNAME 

FROM      S 

WHERE     STATUS  >=ANY  (10,20,30) 


The  result  relation  is: 


SNAME 


Smi  th 
■Jones 
Blake 
Clark 
Adams 


5.   The  Set  Member shi  p  Operator ,   ' < ANY ' 

The  operator,  <ANY,  is  evaluated  as  follows.  The 
condition,  A  <ANY  B,  evaluates  to  be  true  if  and  only  if  the 
value  of  attribute  A  is  less  at  least  one  value  in  the 
enumerated  set  B.  This  implies  that  the  value  of  attribute 
A  is  less  than  the  maximum  value  in  set  B.  The  formal 
predicate  logic  definition  follows: 
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V<  <-  E  A  <==>  x  <  max  {B> ) 

EXAMPLE  6:  If  we  wish  to  obtain  supplier  names  -for 
suppliers  whose  status  is  less  than  30,  we  may 
use  the  following  query: 

SELECT    SNAME 

FROM      S 

WHERE     STATUS  <ANY  (10,20,30) 


The  result  relation  is: 


SNAME 


Smi  th 
Jones 
Clark 


6.   The  Set  Membershi  p  Operator ,  ' >ANY ' 

The  operator,  >ANY ,  is  evaluated  as  -follows.  The 
condition,  A  >ANY  B,  evaluates  to  be  true  if  and  only  if  the 
value  of  attribute  A  is  greater  than  at  least  one  value  in 
the  enumerated  set  B.  The  formal  predicate  logic  definition 
f ol 1 ows: 

Vx  ( x  S  A  <  ==  >  3  Y  ( Y  e  B  |  *  >  y  >  >  ==  > 
V>'  (x  e  A  <==>  x  >  min  <!B>  ) 

EXAMPLE  7:  If  we  wish  to  obtain  supplier  names  for 
suppliers  whose  status  is  greater  than  10,  we 
may  use  the  following  query: 
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SELECT    BNAME 

FROM      S 

WHERE     STATUS  >ANY  (10, 20 , 30  ) 


The  result  relation  is: 


SNAME 


Smi  th 
Blake 
Clark 
Adams 


C.   ALL-MEMBERSHIP  OPERATIONS 

Like  the  comparison  operator,  ANY,  the  operator,  ALL,  is 
used  in  conjunction  with  the  six  standard  relational 
operators.  It  also  specifies  variations  on  the  set 
membership  theme. 

1 .   The  Set  Membershi  p  operator ,   ' =ALL ' 

The  operator,  =ALL ,  is  evaluated  as  follows.  The 
condition,  A  =ALL  B,  evaluates  to  be  true  if  and  only  if  the 
value  of  attribute  A  is  equal  to  every  (each)  value  in  the 
enumerated  set  B.  The  formal  predicate  logic  definition 
f ol 1 ows: 

Vx  (x  £     A  <==>  ^Y  (y6b  I  x  =y>)  A 

V  y  <  y  £  b  <  ==  >  3 x  ( x  £  A  I  >;  =  y  >  > 

From  this  definition,  it  is  apparent  that  the  set  B,  whether 
manually  enumerated  or  determined  by  the  results  of  an  inner 
SELECT,  would  contain  only  one  value  (or  duplicates  of  that 
value).    Therefore,   since  we  can  always  use  a  condition  of 
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the   -form  WHERE  STATUS  =  30,   we  shall  not  use  the   operator 
=ALL  in  -further  discussion  or  examples. 

2.   The  Set  Membershi  p  Operator  ,   '  ""=ALL 

The  operator,  "J=ALL,  is  interchangeable  with  the 
operator,  N0T_IN.  The  condition,  A  *V'=ALL  B,  evaluates  to  be 
true  i -f  and  only  if  the  value  of  attribute  A  is  not  equal  to 
every  value  in  the  enumerated  set  B.  In  other  words,  there 
is  no  value  in  the  set  B  to  which  the  value  of  attribute  A 
is  equal.  The  predicate  logic  definition  of  N0T_IN  is 
repeated  for  clarity: 


Vx  <x  E  A  <==>\/y  <y  E  B  |  x  ■"-  y>) 


The  query  given  in  example  2  (with  "=AI_i_  substituted  for  NOT 
IN)   is  applicable.     In  subsequent  examples   involving   set 
membership,  we  shall  use  NOT  IN  rather  than  "J=ALL. 
3.   The  Set  Membershi  p  operator ,  ' <  =ALL ' 

The  operator,  <=ALL,  is  evaluated  as  follows.  The 
condition,  A  <=ALL  B,  evaluates  to  be  true  if  and  only  if 
the  value  of  attribute  A  is  less  than  or  equal  to  every 
value  in  the  enumerated  set  B.  This  implies  that  the  value 
of  attribute  A  is  <=  the  minimum  value  in  set  B.  The 
predicate  logic  definition  follows: 

Vx  (x  E  A  <==>\/y  (y  E  B  |  x  <=  y))  ==> 
Vx  (x  E  A  <==>  x  <=  min  CB> ) 

Again,   as  in  the  case  of  the  operator  ANY,   our   degenerate 
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examples  utilizing  the  operators  <=ALL,  >=ALL ,  <ALL,  and 
>ALL  will  be  presented  with  enumerated  sets  containing  more 
than  one  member  (even  though,  logically,  only  one  member  is 
necessary) . 


EXAMPLE  8:  If  we  wish  to  obtain  supplier  names  -for 
suppliers  whose  status  is  not  greater  than  10, 
we  may  use  the  -Following  query: 

SELECT    SNAME 

FROM      S 

WHERE     STATUS  <  = ALL  (10, 20 , 30 > 


The  result  relation  is: 


SNAME 


Jones 


Note  that  the  difference  between  the  comparison  operators 
ANY  and  ALL  is  readily  apparent  when  we  compare  this  example 
with  example  4.  In  example  4,  the  operator,  <=ANY,  allows  u< 
to  obtain  supplier  names  for  suppliers  whose  status  is  not 
larger  than  30.  The  result  relation  in  that  example 
includes  the  names  of  all  five  suppliers. 

4.   The  Set  Member shi  p  Operator ,  ' >=ALL ' 

The  operator,  >=ALL ,  is  evaluated  as  -Follows.  The 
condition,  A  >=ALL  B,  evaluates  to  be  true  if  and  only  it 
the  value  of  attribute  A  is  greater  than  or  equal  to  every 
value  in  the  enumerated  set  B.  This  implies  that  the  value 
o-F  attribute  A  is  greater  than  or  equal  to  the  maximum  value 


in  set  B.   The  predicate  logic  definition  follows: 

V*  <x  £  A  <==>\/y  (y  £  B  |  x  >=  y)>  ==> 
V>;  Cx  £  A  <==>  ;:  >=  max  -CB1  ) 


EXAMPLE   9: 


If  we  wish  to  obtain  supplier  names  for 
suppliers  whose  status  is  at  least  30 ,  we  may 
use  the  following  query: 


SELECT    SNAME 

FROM      S 

WHERE     STATUS  >=ALL  (10,20,30) 


The  result  relation  is: 


SNAME 


Blake 
Adams 


5.   The  Set  Member shi  p  operator ,  ' <  ALL ' 

The  operator,  <ALL,  is  evaluated  as  follows.  The 
condition,  A  <ALL  B,  evaluates  to  be  true  if  and  only  if  the 
value  of  attribute  A  is  less  than  every  value  in  the 
enumerated  set  B.   The  predicate  logic  definition  follows: 

V*  (x  £  A  <==>Yy  (y  £  B  |  >;  <  y)  )  ==> 
Vx  <x  ^  A  <==>  x  <  min  €BJ ) 

EXAMPLE   10:     if   we   wi sh   to  obtain   supplier   names   for 

suppliers   whose  status  is  less  than   10,   we 
may  use  the  following  query: 
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SELECT    SNAME 

FROM      S 

WHERE     STATUS  < ALL  ( 1 O , 20 , 30 ) 


The  result  relation  is: 


SNAME 


Note   that   this   is   the   empty   relation.     There  a.r<B       no 
suppliers  whose  status  is  less  than  10. 

6.   The  Set  Membershi  p  Operator ,   " >ALL " 

The  operator,  >ALL ,  is  evaluated  a=  -follows.  The 
condition,  A  >ALL  B,  evaluates  to  be  true  if  and  only  i  f  the 
value  o-f  attribute  A  is  greater  than  every  value  in  the 
enumerated  set  B.   Thp  predicate  logic  definition  -follows: 

Vx  <x  €  A  <==>\/y  <y  E  b  |  >■    >  y>>  ==> 

Vx  (>■    €    a  <==>  x  >  max  CB>  ) 

EXAMPLE   11:     I-f   we   wish  to   obtain   supplier   names   for 

suppliers  whose  status  is  greater  than  30,  we 
may  use  the  following  query: 

SELECT    SNAME 

FROM      S 

WHERE     STATUS  >ALL  (10,20,30) 


The  result  relation  is: 


SNAME 


As  in  example  10,   this  is  the  empty  relation.   There  ar&    no 
suppliers  whose  status  is  greater  than  30. 
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D.   EXPRESSING  IN-MEMBERSHIP  OPERATIONS  IN  ABDL 

In  this  and  the  following  two  sections,  we  present  ABDL 
translations  -for  the  examples  given  in  sections  A,  B,  and  C. 
Each  SQL  example  will  be  repeated,  -followed  by  the  ABDL 
t ran si  at i  on . 

1  .   The  Set  liembershi  p  Operator  ,  '  IN  ' 

The  SQL  query  presented  as  example  1  is 

SELECT    S# , SNAME 

FROM      S 

WHERE     SNAME  IN  (Smi th , Jones) 

Our   proposed  SQL  interface  would  provide  the  following  ABDL 
transl at  i  on : 

RETRIEVE  (((FILE  =  S >  A       (SNAME  =  Smith))   \/ 

((FILE  =  S)  A   (SNAME  =  Jones)))  <S#,SNAME> 

One  conjunction  is  created  for  each  value  in  the   enumerated 

set,   containing   an  equality  predicate.  The  ABDL   request 

will   have   as  many  conjunctions  as  there  &re    values  in   the 
set. 

2  .   The  Set  Member shi  p  operator ,  '  NOT  IN ' 

The  SQL  query  presented  as  example  2  is 

SELECT  S# 
FROM  SP 
WHERE     P#  NOT  IN  (P3,P4) 
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The  ABDL  translation  is 

RETRIEVE  (  (FILE  =  SP)  A   (P#  ""=  P3>  A   (P#  "*=  P4)  <S#> 

One   predicate  o-f  the  -form  (attribute  "w=  value)   is   created 

■for  each  value  in  the  enumerated  set.  The  ABDL  request  will 

contain  a  single  conjunction,  which  is  the  logical  AND  o-f 
these  predicates. 

E.   EXPRESSING  ANY-MEMBERSHIP  OPERATIONS  IN  ABDL 
1  .   The  Set  Membership  Operator ,  ' =ANY ' 

As  previously  de-fined,   =ANY  is  equivalent  to  IN  and 
will  not  be  included  in  our  set  o-f  allowable  SQL  constructs. 

2.  The  Set  Membershi  p  Operator  ,  '  ""=ANY  ' 
The  SQL  query  presented  as  example  3  is 

SELECT  S# 
FROM  SP 
WHERE     P#  "=ANY  (P1,P2) 

The  ABDL  translation  is 

RETRIEVE  (((FILE  =  SP)  A   <P#  ~=  Pi))  V 

((FILE  =  SP)  A   (P3  ~=  P2)  )  )  <S#> 

One  conjunction  is  created  -for  each  value  in  the  enumerated 
set,  containing  a  predicate  of  the  -form  (attribute  "-  = 
val ue) . 

3.  The  Set  Membership  Operator ,   " <  =ANY ' 
The  SQL  query  presented  as  example  4  is 


SELECT    SNAME 

FROM      S 

WHERE     STATUS  <=ANY  (10,20,30) 

The  ABDL  translation  is 

RETRIEVE  ( (FILE  =S)  A       (STATUS  <=  30))  < SNAME > 

One  predicate  o-f  the  form  (attribute  <=  max  value)  is 
created.  The  ABDL  request  will  contain  a  single 
conjunction.  Note  that  the  SQL  inter-face  recognizes  that 
the  condition  in  the  WHERE  clause  evaluates  to  true  i f  and 
only  i  f  a  supplier's  status  is  less  than  or  equal  to  at 
least  one  of  the  status  values  in  the  enumerated  set 
(implying  that  that  supplier's  status  is  less  than  or  equal 
to  the  maximum  value  in  the  set) .  Therefore,  only  the 
maximum  value,  30,  is  utilized  in  the  ABDL  translation. 
4.   The  Set  Member shi  p  Operator ,  ' >=ANY ' 

The  SQL  query  presented  as  example  5  is 

SELECT    SNAME 

FROM       S 

WHERE     STATUS  >=ANY  (10, 20 , 30 ) 

The  ABDL  translation  is 

RETRIEVE  ((FILE  =  S)  A       (STATUS  >=  10))  < SNAME > 

One   predicate   of   the   form  (attribute   >=   min_value)   is 
created.      The    ABDL    request   will   contain    a    single 
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conjunction.  As  in  the  "<=ANY  case,  only  one  value  ot  the 
enumerated  set  in  the  WHERE  clause  is  utilised  in  the  ABDL 
translation.  In  this  case,  the  minimum  value,  10,  is 
uti 1 i  zed. 

5.   The  Set  Membershi  p  Operator ,   ' <  ANY ' 

The  SQL  query  presented  as  example  6  is 

SELECT    SNAME 

FROM      S 

WHERE     STATUS  < ANY  ( 1 0 , 20 , 30 ) 

The  ABDL  translation  is 

RETRIEVE  ((FILE  =  S)  A       (STATUS  <  30))  < SNAME > 

One  predicate  o-f  the  form  (attribute  <  max_value)  is 
created.  The  ABDL  request  will  contain  a  single 
con junc ti  on . 

h>.        The  Set  Membershi  p  Operator  ,  '  >ANY  ' 

The  SQL  query  presented  as  example  7  is 

SELECT    SNAME 

FROM      S 

WHERE     STATUS  >ANY  ( 1 0 , 20 , 30 ) 

The  ABDL  translation  is 

RETRIEVE  ((FILE  =S>  A   (STATUS  >  10))  < SNAME > 


One  predicate  o-f  the  -form  (attribute  minvalue)  is 
created.  The  ABDL  request  will  contain  a  single 
conjunct  i  on . 

F.   EXPRESSING  ALL-MEMBERSHIP  OPERATIONS  IN  ABDL 
1  .   The  Set  Member shi  p  Operator ,   ' =ALL ' 

As  previously  de-fined,  use  o-f  the  operator,  =ALL ,  is 
equivalent  to  using  the  standard  equality  operator,  =.  We 
will,  there-fore,  not  include  it  in  our  set  o-f  allowable  SQL 
constructs. 

2.  The  Set  Member shi  p  Operator ,  ' ^=ALL ' 

As  previously  de-fined,  ""'=ALL  is  equivalent  to 
NOT  IN  and  will  not  be  included  in  our  set  o-f  allowable  SQL 
constructs. 

3.  The  Set  Member shi  p  Operator ,  ' <=ALL ' 
The  SQL  query  presented  as  example  8  is 

SELECT    SNAME 

FROM      S 

WHERE     STATUS  <=ALL  (10,20,30) 

The  ABDL  translation  is 

RETRIEVE  ((FILE  =  S)  A       (STATUS  <=  10))  < SNAME > 

One  predicate  of  the  -form  (attribute  <=  min_value)  is 
created.  The  ABDL  request  will  contain  a  single 
conjunction.  As  in  the  '<=ANY'  case,  the  translator  in  our 
SQL   inter -face   utilizes  only  one  value  -from  the   enumerated 
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set.  Note  that  in  this  case,  the  minimum  value,  10,  is 
chosen,  whereas,  in  the  '<=ANY'  case  the  maximum  value,  30, 
is  chosen. 

4.  The  Set  Membership  Operator ,  ' >=ALL ' 
The  SQL  query  presented  as  example  9  is 
SELECT    SNAME 

FROM      S 

WHERE     STATUS  >=ALL  ( 1 0 , 20 , 30 ) 

The  ABDL  translation  is 

RETRIEVE  ( (FILE  =  S)  A       (STATUS  >=  30) )  < SNAME > 

One  predicate  o+  the  -form  (attribute  >=  maxvalue)  is 
created.  The  ABDL  request  will  contain  a  single 
conjunction.  As  in  the  '  >=ANY '  case,  only  one  value  o+  the 
enumerated  set  is  utilized.  In  this  case,  the  maximum 
value,  30,  is  utilised  in  the  equivalent  RETRIEVE  construct. 
We  recall  that  the  minimum  value,  10,  was  utilized  in  the 
' >=ANY '  case. 

5.  The  Set  Membershi  p  Operator ,  ' < ALL ' 

The  SQL  query  presented  as  example  10  is 

SELECT    SNAME 

FROM      S 

WHERE     STATUS  'ALL  (10,20,30) 

The  ABDL  translation  is 


RETRIEVE  ( (FILE  =  S)  /   (STATUS  <  10) )  <SNAME> 

One  predicate  o-f  the  -form  (attribute  <  min_value)  is 
created.  The  ABDL  request  will  contain  a  single 
con  junct i on . 

6.   The  Set  Membershi p  Operator ,  ' >ALL " 

The  SQL  query  presented  as  example  11  is 

SELECT    SNAME 

FROM      S 

WHERE     ST A  TUS  ) ALL  ( 1 0 , 20 , 30 ) 

The  ABDL  translation  is 

RETRIEVE  ((FILE  =  S)  A   (STATUS  >  30))  < SNAME > 

One  predicate  o-f  the  form  (attribute  >  max_value)  is 
created.  The  ABDL  request  will  contain  a  single 
con junct i  on . 
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V.  SELECTIONS  WITH  SET  MEMBERSHIP  OPERATIONS  ON 
MULTIPLE  RELATIONS 

In  the  preceding  chapter,  we  have  described  SQL  SELECT 
queries  which  utilize  the  comparison  operators,  IN,  ANY,  and 
ALL  in  the  WHERE  clause.  These  e.re  simple,  si  ngl  e— r  el  at  i  on 
queries  in  which  the  associated  sets  a^re  enumerated.  We  now 
discuss  the  nested  SOL  SELECT  queries  (or  nested  mapping)  in 
which  the  result  of  one  mapping  is  used  in  the  WHERE  clause 
of  another  mapping.  In  other  words,  the  membership  of  the 
set  following  IN,  ANY,  or  ALL  in  one  SELECT  operation  is 
determined  by  the  result  set  of  another  SELECT.  We  will 
describe  the  operation  of  two— level,  three— level  and  n— level 
nested  SELECTS  in  Sections  A,  B,  and  C,  respect i vel v .  In 
Section  D,  we  show  how  the  nested  SOL  SELECT  is  translated 
into  a  series  of  ABDL  RETRIEVES. 

A.   NESTED  SELECTIONS  WITH  TWO  RELATIONS 

As  previously  stated,  in  a  nested  SOL  SELECT,  the 
results  of  one  SELECT  operation  ar^  used  in  the  WHERE  clause 
of  another  SELECT  operation.  We  view  the  former  SELECT  as 
the  inner  (level  of)  SELECT,  and  the  latter  as  the  outer 
(level  of)  SELECT.  Figure  8  depicts  an  example  of  a  two- 
level  nested  SELECT  operation.  This  particular  example  is 
chosen  for  its  similarity  to  one  of  our  examples  in  Chapter 
IV  (i.e.,   Example  6)  which  utilizes  the  operator,   <ANY,  in 
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conjunction  with  a  manually  enumerated  set.  In  the 
degenerate  case  presented  in  that  example,  the  operator, 
<ANY,  appeared  to  be  of  marginal  use-fulness.  The  use-fulness 
o-f  this  and  similar  operators  (e.g.  ,  <=ANY,  >=ALL)  in  the 
nested  SELECT,  will  now  become  apparent. 

Both  ou.r  current  example  in  Figure  S,  and  Example  6  of 
Chapter  IV  result  in  a  set  of  supplier  numbers  for  suppliers 
with  status  value  less  than  the  current  maximum  status  value 
in  the  S  table.  In  our  degenerate  example,  we  must  know 
(i.e. ,  enumerate)  that  that  value  is  30.  In  our  present 
example,  we  allow  an  inner  SELECT  to  obtain  the  status  value 
for  each  supplier  number  in  the  S  table.  By  employing  an 
inner  level  of  SELECT,  we  aire  free  from  enumerating  the 
val ues. 


Outer 
SELECT 

Inner 


SELECT 


SELECT    S# 

FROM      S 

WHERE     STATUS  <ANY 

(SELECT    STATUS 
FROM      S) 


Figure  8.   A  Two— Level  Nested  SELECT 

Processing  of  the  two-level  nested  SELECT  in  Figure  S 
proceeds  as  follows.  First,  the  inner  SELECT  retrieves  all 
status  values  in  the  S  table.  The  result  of  this  SELECT  is 
the  set  (with  duplicates)  of  status  values  C20, 10,30,20,30} . 
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The  outer  SELECT  then  selects  supplier  numbers  FROM  table  S 
WHERE  the  status  value  is  less  than  at  least  one  of  the 
values   in   the  above  result  set.    The  result   relation   is 


S# 


SI 
S2 
S4 


B.   NESTED  SELECTIONS  WITH  THREE  RELATIONS 

We  now  describe  a  three— level  nested  SELECT.  We  present 
an  example  which  demonstrates  the  usefulness  of  the 
set /compar i son  operator  IN,  and  o-F  multi— level  SELECTS  in 
general.  In  the  course  o-f  providing  the  requested  data, 
this  three— level  SELECT  chooses  data  from  each  o-f  the  three 
tables  which  comprise  our  sample  database.  The  request  is 
to  get  supplier  names  for  suppliers  who  supply  at  least  one 
red    part.   The  query  is  presented  in  Figure  9. 


'        SELECT 

SNAME 

Outermost 

FROM 

S 

SELECT 

WHERE 

S#  IN 

r 

(SELECT 

S# 

Inner 

< 

FROM 

SP 

SELECT 

> 

WHERE 

P#  IN 

t 

(SELECT 

P# 

Innermost 

< 

FROM 

P 

SELECT 

. 

WHERE 

COLOR  = 

RED 

)  ) 

Figure  9.   A  Three-Level  Nested  SELECT 
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Processing  of  the  query  in  Figure  9  proceeds  as 
•foil  ows. 

Step  1:  The  innermost  SELECT  retrieves  part  numbers 
(P#)  -from  the  parts  relation  (P)  where  the  color 
o-f  the  parts  is  red.  The  result  of  this  SELECT 
is   the   set   o-f   part   numbers  €P1,P4,P6J. 

Step  2:  The  next  SELECT  retrieves  supplier  numbers  (S#> 
from  the  shipments  relation  (SP)  where  P#s  are 
in  the  result  set  o-f  step  1.  The  result  o-f  this 
SELECT  is  the  set  o-f  supplier  numbers  £S1,S2,S4>. 

Step  3:   The  outermost   SELECT   retrieves   supplier  names 

(SNAME)   -from   the  suppliers  relation    (S)  where 

S#s  e,re    in  the  result  set  of  step  2.   The  result 
relation  passed  to  the  user  is     SNAME 


Smi  th 
Jones 
Clark 


C.   NESTED  SELECTIONS  WITH  N  RELATIONS 

Although  it  seems  unlikely  that  many  users  would  utilize 
a  nested  SELECT  of  more  than  2  or  3  levels,  the  subqueries 
can  be  nested  to  any  depth.  The  form  of  an  n— level  nested 
SELECT  is  shown  in  Figure  10. 

The  SET_0PR  in  Figure  10  refers  to  the  various  forms  of 
our  comparison  operators  IN,  ANY,  and  ALL.  In  the  next 
section,  we  describe  the  translation  of  nested  SELECTs  to  a 
series  of  ABDL  RETRIEVES.    Therefore,   it  is  important  that 
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SELECT  5sl_evprjist 
FROM    rei ati on_name_l 
WHERE   attribute_namel  SET_QPR 
(SELECT  attribute_namei 
FROM    relatian_name_2 
WHERE   attribute  name2  SET  OPR 


level  i  or 
>  outermost 
SELECT 


level  2 
}   inner 
SELECT 


or 


(SELECT  attribute_name (n-1 ) 
FROM    rel at i on_name_n 
WHERE   condition)...) 


level  n  or 
i  nnermost 
SELECT 


Figure  10.   An  N-Level  Nested  SELECT 

we   note  the  -following  information  as  succinctly   stated   in 

CRe-f.  13. 

"The  nth  level  is  the  i  nnermost  SELECT.  The  1st 
level  is  the  outermost  SELECT.  The  sel _expr _1  i st  o-f  each 
i  nner  SELECT,  i.e.,  a  SELECT  lower  than  level  i,  contains 
a  single  attribute  name,  which  is  the  same  as  the 
attribute  name  used  in  the  qual  i -f  i  cati  on  o-f  the  next- 
higher  level  SELECT.  The  relation  names  at  any  two  levels 
may  be  the  same. " 

D.   TRANSLATING   NESTED   SELECTIONS   TO   A   SERIES   OF   ABDL 
RETRIEVALS 

As    shown    by   Macy    CRe-f.    8D,    there    exists    a 

straight-forward  mapping  between  the  SQL  SELECT  operation  and 

the   ABDL   RETRIEVE  operation.    We  can,  therefore,  simulate 

the    nested   SELECT   with   a   series   of   RETRIEVES,    each 

succeeding  operation  using  the  results  of  the  previous   one. 

Thus,  referring  to  our  three-level  example  of  Section  B,  the 
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ABDL  equivalent  of  the  innermost  SELECT  is 

RETRIEVE  ((FILE  =  P)  A       (COLOR  =  'RED'))  <P#> 

The  resulting  set  o-f  part  numbers  £P1,P4,P6J  is  then  used  in 
the  next  ABDL  operation  as  -follows: 

RETRIEVE  (((FILE  =  SP)  A  (P#  =  PI))  V 
((FILE  =  SP)  A  (P#  =  P4))  V 
( (FILE  =  SP)  A       (P#  =  P6)))  <S#> 

The  last  retrieve  (corresponding  to  the  outermost  SELECT  in 
our  example)  then  uses  the  resulting  set  o-f  supplier  numbers 
CS1,B2,S4J  as  follows: 

RETRIEVE  (((FILE  =  S)  A  (S#  =  Si))  V 
((FILE  =  S)  A  (S#  =  S2) )  V 
( (FILE  =  S)  A       <S#  =  S4>>>  <SNAME> 

It  is  intended  that  the  operation  of  our  SQL  interface  be 
transparent  to  the  SQL  user.  Therefore,  the  resulting 
values  of  the  attribute  BNAME  (Smi th , Jones , CI  ark )  ar& 
returned  to  the  user  in  the  form  of  the  result  relation 
previously  described  for  our  three— level  nested  SELECT 
example  of  section  B. 

We  have  now  demonstrated  the  operation  of  data 
retrievals  involving  the  nested  SELECT  construct.  These 
nested  operations  may  include  use  of  the  various  forms  of 
IN,   ANY,   and   ALL.    The  sequence  of  actions  necessary   to 
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translate  the  nested  SQL  SELECT  to  a  series  o-f  ABDL 
RETRIEVES  has  been  described.  In  the  next  chapter,  we 
present  our  proposals  for  the  implementation  o-f  these 
t ran si  at  i  ons. 
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VI.    IMPLEMENTING  NESTED  SELECTIONS 

The  logical  process  by  which  a  nested  SQL  SELECT  is 
translated  to  a  series  of  ABDL  RETRIEVES  has  been  described. 
It  is  clear  that  each  SELECT  level,  -from  the  innermost  to 
the  outermost,  must  be  translated  to  an  ABDL  RETRIEVE. 
Then,  each  RETRIEVE  is  processed  in  turn,  with  each 
succeeding  operation  utilizing  the  results  o-f  the  previous 
RETRIEVE  in  the  QUERY  part.  In  Section  A  o-f  this  chapter,  we 
present  the  algorithms  for  building  the  ABDL  QUERY.  In 
Section  B,  a  simple  iterative  structure  for  controlling  the 
execution  of  n— level  nested  SELECTS  is  provided.  Finally, 
in  Section  C,  the  overall  software  structure  of  our  SQL 
interface  will  be  proposed.  Note  that,  as  we  continue  our 
bottom— up  investigation  and  include  additional  SQL 
operations  in  our  set  of  allowable  constructs,  the 
functionality  of  this  structure  may  be  augmented.  However, 
it  is  expected  that  the  software  structure  will  remain 
i  ntact . 

A.   ALGORITHMS  FOR  BUILDING  THE  ABDL  QUERY 

We  recall  that  the  Query  part  of  ABDL  RETRIEVES  (DELETE 
and  UPDATE,  as  well)  is  written  in  a  disjunctive  normal 
form.  A  QUERY  may  be  a  single  conjunction  or  it  may  be  a 
disjunction  of  conjunctions.  The  number  of  conjunctions 
generated  in  the  translation  of  nested  SELECTS  utilizing  the 
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various  forms  of  IN,  ANY,  and  ALL  has  been  noted  in  Sections 
D,  E,  and  F  of  Chapter  IV.  Figure  11  summarizes  this 
information.  The  figure  also  specifies  the  relational 
operators  involved,  as  well  as  the  source  of  the  values  to 
be  used  in  each  conjunction. 

Set  Qpr     #  Conjunctions     Rel  Qpr     Value  Source 


IN 

NOT  I N 
"V=ANY 

<  =ANY 
>=ANY 

<  ANY 
>ANY 

<  =ALL 
>=ALL 
<ALL 

:  ALL 


result  set 
resul t  set 
result  set 
max (resul t 


set) 


mi n (result  set) 

max (result  set) 

mi n (result  set) 

mi n (result  set) 

max (result  set) 

mi n (result  set) 

max (result  set) 


Fi  qure  1 1 . 


Summary  of  Nested  SELECT 
Set  Comparison  Operators 


From  Figure  11,  it  is  clear  that  our  translator  must 
perform  a  multiway  selection  depending  upon  which  set 
comparison  operator  is  utilized  at  each  SELECT  level.  We 
describe  an  appropriate  algorithm  in  Subsection  1.  It  can 
also   be   seen  that,   in  the  case  of  the   operators   IN   and 
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"**=ANY ,  a  number  of  conjunctions  are  generated,  one  for  each 
value  in  the  result  set  of  the  previous  operation.  In 
Subsection  2,  we  present  an  n— con junct i on  algorithm  to 
handle  these  two  cases.  Note  that  in  all  remaining  cases,  a 
single  conjunction  is  generated.  The  1 —con junct i on 
algorithm  is  presented  in  Subsection  3. 

1 .   The  Query— Constructor  Subrout i  ne 

As  noted  above,  the  top  — level  translator  portion  o-f 
our  SDL  interface  must  determine  from  the  set  comparison 
operator  the  proper  algorithm  for  constructing  the  QUERY 
part  of  the  resultant  ABDL  request.  This  can  be  handled  by 
a  multi-way  selection  ar  CASE  construct,  as  shown  in  the 
Query— Constructor  Algorithm  in  Figure  12.  The  parameters 
passed    to     Quer  y_Constructor    are  QueryTempl ate    (a 

conjunction,  described  in  Subsection  2,  constructed  to 
facilitate  the  incorporation  of  succeeding  result  sets),  the 
Result _Set  of  the  previous  request,  and  the  appropriate 
Set_Opr  from  Figure  11. 

In  each  alternative  of  the  CASE  statement  of  Figure 
12,  the  correct  relational  operator  is  chosen,  and  either 
the  n— con junc t i on  or  the  1— con junct i on  subroutine  is  called. 
The  parameters  provided  for  each  subroutine  call  are  the 
relational  operator  and  the  result  set  of  the  previous 
operation,  or  the  ma>:  i  mum/mi  ni  mum  value  of  the  result  set. 
As  previously  discussed,  when  ANY  and  ALL  are  used  with 
these  relational  operators,  only  one  value  of  the  result  set 
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Subroutine  Qu8ry_Constructor (GuBry_Tempiats,Resuit_Set , 

Set _Opr  > 
CASE  SetJDpr  OF 

IN:       Rei_Qpr  < —  '=' 

call  N_conjuncti  on  ( Query  _Templ  ate  ,  Resutl  t_Set , 

Rel_Opr ) ; 

NOT  IN:   RelJDpr  < —  "*= ' 

call  Qne_con junct i  on (Query_Tempi  ate , Resul  t _Set , 

Rei_Opr )  ; 

~=ANY:    Reljjpr  < —  '~J=' 

call  N_con junct i  on (Query_Templ ate , Resul  t_Set , 

Rel_Opr > ; 

<  =ANY :    Re  1  _0p  r  <  —  '  <  =  ' 

cal  1  One_con junct i  on (Quer y_Templ ate , 

max (Resul t_Set) , Rel_Qpr> ; 

>=ANY:    Rel_Opr  < —  ' >= ' 

call  One_con junct i  on (Query_Templ ate , 

mi  n (Resul t_Set )  , Rel _Opr )  ; 

<ANY:      Rel_Opr  < —  '< * 

cal  1  One_c on junct i  on (Query_Templ ate, 

max (Resul t_Set) ,Rel _Opr ) ; 

>ANY:      Rei_Opr  < —  *>" 

cal 1  One_con junct i on (Query_Templ ate , 

min (Resul t_Set) , Rel_Opr ) ; 

<  = ALL :    Re 1 _0p  r  <  —  ' <  = ' 

call  One_con junct i  on (Query_Templ ate , 

mi  n ( Resul t  _Set )  , Rel _Opr )  ; 

>=ALL:    Rel_Opr  < —  ' >= ' 

cal  1  One_con juncti  on (Query_Templ ate , 

max (Resul t_Set) ,Rel_Opr) ; 

<ALL:      Rel_Opr  < —  '< ' 

cal 1  One_con juncti  on (Query_Templ ate , 

mi  n (Resul t_Set )  , Rel _Opr )  ; 

>ALL:      Rel_Opr  < —  '>' 

call  One_con junct i  on (Query_Templ  ate , 

max (Resul t_Set) ,Rel_Opr) ; 
END  CASE 

END  Query_Constructor 

Figure  12.   The  Query_Constructor  Subroutine 
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15  utilized  in  the  translation.  Depending  upon  which  -form 
o-f  the  set  comparison  operator  is  used,  the  selected  value 
will  be  either  the  maximum  or  the  minimum  value  in  the 
result  set.  There-fore,  a  call  to  a  standard  Max  ar  Min 
■function,  as  appropriate,  must  be  made  prior  to  sending  the 
resultant  single  value  to  the  1— con junct i on  subroutine.  It 
should  be  noted  that  the  1— con junct i on  subroutine  is  called 
in  the  case  o-f  the  operator  NOT  IN.  However,  there  is  no 
need  to  utilize  a  Max/Min  function.  We  also  note  that  a 
call  to  Max/Min  is  never  needed  prior  to  a  call  to  the  n— 
conjunction  subroutine. 

2.   The  N— Con junct i  on  Subrout i  ne 

In  the  case  o-f  the  set  operators  IN  and  "J=ANY  .  the 
above  Query— Constructor  subroutine  will  call  the  n  — 
conjunction  subroutine.  In  the  process  of  translating 
nested  SELECTS  which  utilize  these  operators,  one 
conjunction  o-f  the  -form 

((FILE  =  Relname)  A       (Attrname  Rel _opr  Value)) 

will  be  generated  -for  each  value  in  the  result  set.  These 
conjunctions  ar&  ORed  to  -form  a  disjunction  o-f  conjunctions, 
as  explained  in  Chapter  IV,  Sections  D  and  E.  An 
algorithmic  representation  o-f  the  n— con  junct  i  on  generation 
subroutine  is  provided  in  Figure  13. 

The  template,  de-fined  in  Figure  13,  is  provided  by 
the  top-level  translator  as  it  translates  each  SELECT   level 
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to  an  ABDL  RETRIEVE.  Val ue_ot _Tempi ate  is  the  only  variable 
which  requires  substitution.  For  the  innermost  (nth  level) 
SELECT  or  a  nested  SELECT  request,  the  equivalent  RETRIEVE 
can  be  constructed  completely.  However,  at  translation 
time,   the   values  to   be   used  in  the   query  portion  of  the 

Sub rout i ne  N_con junct i on (Query_TempI ate ,  Rel _opr ) 

/*  Query_Templ ate:  */' 

/*  is  ((FILE  =  Relname)  A   (Attrname  Rel _opr  Value))  */ 

/*  Query:  */ 

/*  is  Query_Templ ate  V    Query_Templ ate   V  .            */ 

/*  V  Query_Templ ate  #/ 

/*  */ 

/*  For  every  value  in  the  Result _set  */' 

/*  generate  one  conjunction  using  Template  */ 

/*  then  OR— concatenate  into  Query.  */ 

Rel  _opr  _o-f  _Templ  ate  < —  Rel_opr 

i±   Result_set  is  NOT  EMRTY 
then 

Val  ue_of  _Templ  ate  < —  1st  value  -from  Result  _set 
Query  < —  Query_Templ  ate   /*  Relname  &  Attrname      */' 

/*  filled  in  * / 

whi 1 e  more  values  in  Result_set  do 

Val  ue_o-f  _Templ  ate  < —  next  value  -from  Resultset 
Query  < —  Query  ! !    V   ! i  Template 
end  whi 1 e 
el  se 

Query  < —  '  '   /*  Query  is  nil  */ 

END  N_con junct i on 

Figure  13.   The  N— con junct i on  Subroutine 

remaining  n  — 1  SELECTS  are  unknown.  There-fore,  the  template 
is  provided  to  the  N— con  junct  i  on  generator  which  -fills  in 
the  missing  values  and  constructs  the  QUERY  part  of  each 
RETRIEVE. 
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3.   The  1  — Con  junc ti  on  Sub rout  1  ne 

In  the  case  o-f  the  operator  NOT  IN  and  all  o-f  the 
ANY/ALL  operators  containing  <=,  >= ,  <,  or  >,  the  CASE 
statement  causes  a  call  to  the  1— con juncti on  subroutine.  As 
described  in  Chapter  IV,  one  predicate  o-f  the  -form 
(Attribute  Rel_opr  Value)  is  generated  -for  each  value  in  the 
result  set.  These  predicates  ^re  then  ANDed  to  -form  a 
single  conjunction.  An  algorithmic  representation  o-f  the  I  — 
conjunction  subroutine  is  provided  in  Figure  14. 


Sub r out i  ne  One_con juncti on (Query_Templ ate , Resul t_set , 

Rel_opr ) 

/*  Query_Templ  ate:  */ 

/*    is  ((FILE  =  Relname)  A   (Attrname  Rel_opr  Value))  */ 

/*  Predicate:  */ 

/*    is  (Attrname  Rel _opr  Value)  */ 

/*  Query:  */ 

/*    is  Query_Templ ate  A   Predicate  A   ...  */ 

/*                        A   Predicate  */ 


Strip  right  paren  -from  Query_Templ ate 
Rel  _opr_o-f  _Templ  ate  < —  Rel_opr 

if  Resul t_set  is  NOT  EMPTY 
then 

Val  ue_o-f  _Templ  ate  < —  1st  value  -from  Resul  t_set 
Query  < —  QueryTempl ate 

whi 1 e  more  values  in  Resul t_set  do 

Val  ue_o-f  _Predi  cate  < —  next  value  -from  Resultset 
Query  < —  Query  ! !   'A    !  S  Predicate 
end  whi 1 e 
el  se 

Query  < —  '      /*  Query  is  nil  */ 
Query_Templ ate  < —  Query_Templ ate  ! !   ') 

Figure  14.   The  1— con juncti on  Subroutine 
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Note,  in  Figure  14,  that  the  template  provided  to  the  i 
conjunction  subroutine  is  identical  to  that  used  in  the  N— 
conjunction  subroutine.  An  additional  data  structure, 
Predi  cate  is  defined  as  (Attrname  Rel_opr  Value).  The  use 
o-f  this  additional  template'  allows  us  to  extend  the  single 
con junct i  on , 

((FILE  =  Relname)  A   (Attrname  Rel  _opr  Value)) 

to  the  mul t i  pi e— predi  cate  si  nql e  conjunction, 

( (FILE  =  Relname)  A   (Attrname  Rel_opr  Value)  A 

A   (Attrname  Rel  op r  Value)) 

The   number   o-f   predicates  generated  is  determined   by   the 
number  of  values  in  the  Result_set. 

B.    AN   ITERATIVE  STRUCTURE  FOR  CONTROLLING  THE  EXECUTION 
OF  N-LEVEL  SELECTIONS 

In   the  previous  section,   we  have  presented  algorithms 

for  building  the  QUERY  part  of  each  ABDL  RETRIEVE   generated 

in  the  translation  of  a  nested  SQL   SELECT.   We  now  consider 

the  process  of  controlling  the  execution  of  this  process,  An 

algorithmic   representation   of  a  simple  structure   for   the 

control   o-f  this  iterative  process  is  provided  in  Figure  15. 

This   N_l evel _Sel ect   subroutine  is  called  by  the   Top-level 

process   o-f   the  interface  (described  in   Section   C).     The 

parameters  passed  include  a  series  o-f  ABDL  RETRIEVE  requests 

(in  the  form  of  a  request  stack) ,  and  the  number,  n,  of  such 


requests.  We  recall,  -from  Chapter  V,  that  the  innermost 
SELECT  level  is  viewed  as  the  nth— level.  Request_Stack  has 
the  ABDL  translation  of  the  nth-level  SELECT  on  top.  The 
1st  — level  SELECT  is  on  the  bottom.  The  stack  is  -formed  in 
this  order  because  the  nth— level  request  is  the  only  request 
containing  a  -fully  formed  query_part  (as  described  in 
Chapter  V)  .  Each  of  the  other  n— 1  requests  requires  the 
Result_set  of  the  immediately  preceding  request  before  it 
can  be  sent  to  MDBS  for  processing. 

Subroutine  N_l evel _Sel ect (Request _Stack , n ) 

/*  Request_Stack  has  the  ABDL  translation  of  the  *■/ 

/*  nth-level  SELECT  on  top.   The  Ist-level  SELECT  */ 

/#  is  on  the  bottom.   Each  request  in  the  Stack  is  *■/ 

/*  composed  of  the  reserved  word  RETRIEVE,  Target_List,  */ 

/*  Set_Opr,  and  Query_Part.   The  Query_Part  of  the  */ 

/*  nth-level  SELECT  is  fully  formed.   The  QueryjPart  */ 

/*  of  the  n— 1  — >  1st— level  SELECTS  is  a  query  template  */ 

/*  having  the  form  */ 

/*  ((FILE  =  Relname)  A   (Attrname  Rel_opr  Value))  */ 

/#  with  a  blank  in  the  'Value'  position.  */ 

Current_Request  < —  Pop (Request_Stack ) 
Send (Current_Request ) 
Reci  eve (Resul t_Set ) 

for  i  < —  1  to  n— 1  do 

Curr ent_Request  < —  Pop (Request _Stack ) 

Cal 1  Query_Constructor (Query_Part , Resul t_Set , Set_Opr ) 

Send (Current _Request ) 

Recei  ve (Resul t_Set ) 
end  for 
Di  spl ay (Resul t_Set ) 

end  N  level  Sel ect 

Figure  15.   An  Iterative  Process  for  Controlling 
the  execution  of  N-level  SELECTS 
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The  operation  of  the  N_l evel _Sei ect  subroutine  is  as 
-follows.  The  nth  — level  request  is  popped  art  the  top  of 
Request_Stack  and  becomes  the  Current_Request  This 
Current  Request  is  forwarded  to  MDBS  through  the  Send 
function.  Upon  completion  of  processing,  the  Result_set  is 
obtained  through  the  Recei  ve  function.  The  remaining  n— 1 
requests  are  popped  off  the  stack  and  processed  in  order. 
The  nth  and  succeeding  result  sets  ^re  incorporated  into 
each  request  through  a  call  to  Query— Constructor  (described 
in  Section  A).  The  Send  and  Receive  functions  ^re  used  on 
each  iteration  to  route  request /resul t  traffic  between 
N_i evel _Sel  ect  and  MDBS.  When  the  last  request  has 
completed  processing,  the  final  result  set  is  provided  to 
the  user  through  a  call  to  the  Pi  spl ay  subroutine.  Display 
presents  the  results  of  the  original  nested  SQL  SELECT  as  a 
resul t  rel at i  on  (this  is  the  format  expected  by  a  SQL  user). 

C.   PROPOSED  SOFTWARE  STRUCTURE 

In  this  section,  we  present  a  software  structure  for  the 
implementation  of  nested  selections  in  our  proposed  SQL 
interface.  In  fact,  all  of  the  translations  heretofore 
introduced  in  this  thesis  and  in  Macy  CRef.  8],  are 
supported  by  this  structure.  Therefore,  allowing  for 
possible  modifications  required  to  support  additional 
multiple  and  si ngl e— rel at i on  SQL  operations,  the  software 
structure  depicted  in  Figure  16  represents  the  over a 1 1 
software  structure  of  the  SQL  interface. 
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As  depicted  in  Figure  16,  the  SQL  interface  is  comprised 
of  a  single  top— level  process  with  multiple  subroutines  and 
functions.  The  top-level  process  is  called  SQLI  (SQL 
Interface).   We  have  described  the  N  level  Select  subroutine 


SQLI 


Get_SQL 
Querv 


SQLT 


Send 


Recei  ve 


Di  spl ay 


N_l evel 
Sel ect 


Query  Constructor 


1  conjunction 


N  Conjunction 


Figure  16.  The  Proposed  Software  Structure 

group.    We  discuss  the  remaining  subroutines  as  we   explain 

the   functionality  of   SQLI.    An   algorithm   for   SQLI   is 

presented  in  Figure  17. 
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The  operation  o-f  SQLI  is  an  -follows.  Once  a  session  is 
initiated  from  the  user  terminal,  the  actions  depicted  in 
ALGORITHM  SQLI  &re  repeated  until  session  termination.  The 
SQL  query  to  be  translated  into  the  equivalent  ABDL 
construct  is  obtained  through  a  call  to  the  subroutine 
Get_SQL_Query .     This  subroutine  polls  the  user  terminal  -for 

ALGORITHM  SQLI 

Repeat 

CALL  Get _SQL_Query (Query) 

CALL  SQLT( Query , Request _S tack, N, Errors) 
if  N  =  0  then    /*  Syntax  Errors  */ 
CALL  Display (Query) 
CALL  Di spl ay (Errors) 
el  se  i-f  N  =  1  then    /*  Single  Request  */ 
Send (Pop (Request_Stack )  ) 
Recei  ve (Resul t_Set ) 
CALL  Display (Resul t_Set) 
el se  .  /*  N— level  Request  */ 

CALL  NJevel  _Select  (Request_Stack  ,N) 
end  i-f 
End_o-f  _sessi  on? 
unti  1  end_o-f  _sessi  on 
end  ALGORITHM  SQLI 

Figure  17.   The  Top  — level  Process  o-f  the  Inter-face,  SQLI 

input.  Note  that  when  a  query  is  obtained,  the  polling 
stops  until  the  result  relation  is  received  by  the  user  (or 
syntax  errors  Are  displayed  -for  the  user).  This  restriction 
is  placed  in  order  to  preclude  the  complexity  o-f  processing 
more  than  one  request  at  a  time.  (We  assume  that  several 
user  terminals  have  access  to  a  copy  of  SQLI,  and  that  each 
user  makes  a  request  and  waits  for  a  result  before  making 
another  request). 
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The  query  obtained  by  the  call  to  Get_SQL_Query  is 
passed  as  a  parameter  in  a  call  to  the  SQL  Translator 
(SQLT)  subroutine.  SQLT  parses  the  query,  recognizes  the 
query— type,  checks  -for  syntax  errors,  and  translates  the  SQL 
query  to  the  appropriate  ABDL  request.  I-f  there  3.re  no 
syntax  errors,  SQLT  places  the  translated  requests  in  a 
stack  and  returns  this  Request_Stack ,  along  with  the  number, 
N,  of  requests  in  the  stack.  In  the  case  of  simple,  single- 
relation  operations,  Request_Stack  contains  one  request.  In 
the  case  of  a  nested  selection,  SQLT  first  parses  and 
translates  the  outermost  SELECT  placing  the  resultant 
RETRIEVE  request  on  the  stack.  As  previously  discussed,  the 
request  contains  a  query— tempi  ate.  (Recall  that  only  the 
nth  — level,  or  innermost,  request  is  fully  formed).  If  there 
are  syntax  errors ,  SQLT  returns  a  value  of  zero  for  N.  The 
errors,    are    also  returned. 

If  the  number  of  requests  in  Request_Stack  is  zero  (N  = 
0)  ,   then   SQLT  has  detected  syntax  errors,.  In  this   case, 

SQLI  makes  two  calls  to  the  Display  subroutine  in  order  to 
provide  the  user  a  display  of  the  query  and  of  the  errors 
detected.  If  the  number  of  requests  in  Request _Stack  is  one 
(N  =  1) ,  then  the  single  request  is  popped  off  the  stack  and 
forwarded,  via  the  Send  function,  to  MDBS  for  processing. 
The  Result_set  is  obtained  through  the  Recei ve  function. 
The  result  relation  is  provided  to  the  user  through  a  call 
to   the  Pi spl ay  subroutine.     If  the  number  of   requests   in 
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Request_Stack  is  greater  than  one,  then  N_l evel _Sel ect  is 
called.  The  subsequent  processing  is  explained  in  Section 
B. 

As  previously  discussed,  we  propose  that  the  SQL 
interface  be  implemented  such  that  SQLI  and  its  subroutines 
a^re  resident  on  a  host  computer.  This  precludes  the  need  to 
place  an  additional  workload  on  the  MDBS  Controller.  In 
effect,  MDBS  is  "unaware"  that  the  user  is  making  database 
requests  in  SQL,  and  the  user  need  only  know  what 
information  is  desired  and  how  to  form  the  request  in  the 
syntax  of  SQL.  The  logical  structure  of  the  system  is 
depicted  in  Figure  18. 
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Figure  IS.   The  Logical  Structure  of  the  System 


81 


VII.   ADDITIONAL  5QL-TQ-ABDL  TRANSLATIONS 

We  have  described  single-relation  set  membership  and 
multiple-relation  nested  SQL  SELECT  operations.  For  each 
SQL  operation,  we  have  developed  the  appropriate  ABDL 
translation.  In  Chapter  VI,  we  have  proposed  a  software 
structure  to  -facilitate  the  implementation  of  these 
translations,  in  addition  to  the  simple,  si nqi e— rel at i on 
translations  which  Macy  CRef  .  81  has  provided.  In  this 
chapter,  we  investigate  other  selected  si ngl e— rel at i on  and 
multiple-relation  SQL  operations.  Inclusion  of  these  highly 
desirable  options  in  the  SQL  set  operations  supported  by  the 
interface  further  demonstrates  the  power  of  ABDL  to  support 
relational  operations. 

As  in  previous  chapters,  the  approach  of  this  chapter  is 
to  describe  each  SQL  operation  and  then  determine  which  ABDL 
constructs  can  be  used  to  support  the  operation.  As  each 
translation  is  developed,  we  show  graphically, 
al gor i thmi cal 1 y ,  and  through  text  how  the  software  structure 
of  the  interface  (described  in  Chapter  VI)  must  evolve  in 
order  to  accomodate  the  additional  operations.  The  single- 
relation  operations  are  presented  in  Section  A,  and  the 
multiple-relation  operations  are  presented  in  Section  B.  In 
Section  C,  we  present  the  modified  software  structure  of  the 
SQL  interface. 
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A.   SELECTED  SINGLE-RELATION  OPERATIONS 

The  single-relation  operations  selected  -for  discussion 
in  this  section  include:  updating  multiple  attributes  in  a 
single  retard;  retrieving  groups  o-f  attributes  which  satisfy 
a  group  condition;  retrieving  computed  values;  providing 
-format  options;  retrieving  ordered  attributes  (SORT);  and 
eliminating  duplicates  (PROJECTION).  These  operations  a.re 
commonly  supported  in  commercial  relational  database  systems 
utilizing  the  SOL  language.  A  SOL— trained  user  o-f  the 
inter-face  proposed  in  this  thesis  would  expect  to  be  able  to 
utilize  familiar  SOL  constructs  to  perform  these  operations. 
We  address  the  SQL-TO— ABDL  translations  in  the  following 
subsect i  ons. 

1 .   Updati  nq  Mul t i  pi e— Attr i  butes 

All  data  languages  provide  a  data  update  capability. 
Of  interest  here  is  the  SOL  construct  for  update.  This 
construct  allows  the  user  to  change  the  values  of  any  number 
of  attributes  stored  in  the  record  by  issuing  a  single 
query.  This  capability  is  both  convenient  and  efficient. 
The  following  example  depicts  the  updating  of  multiple- 
attributes  (fields)  in  a  single  record.  If  we  wish  to 
change  the  color  of  part  P2  to  yellow,  increase  its  weight 
by  5,  and  set  its  city  to  Normandy,  we  may  use  the  following 
SOL  query: 
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UPDATE 

P 

SET 

COLOR 

=  ' Yel 1 ow  , 

WEIGHT 

=  WEIGHT  +  5, 

CITY 

=  '  Normandy ' 

WHERE 

P# 

=  'P2* 

In  this  example,  we  a.re  updating  the  attributes  COLOR, 
WEIGHT,  and  CITY  in  a  single  record  with  primary  key,  P2. 
The  record  is  contained  in  the  Parts  (P)  relation.  Note 
that  any  reference  to  an  attribute  on  the  right— hand  side  of 
an  equals  sign  refers  to  the  value  of  that  attribute  pr i  or 
to  updating. 

In  studying  the  SQL  example  above,  we  note  that 
there  are  three  cases  to  consider  depending  on  the 
attributes  listed  in  the  SET  and  WHERE  clauses.  We  refer  to 
these  as  case— 0,  case— 1,  and  case— 2  updates.  To  facilitate 
the  following  explanation,  let  S  be  the  set  of  distinct 
attribute  names  listed  in  the  SET  clause,  and  W  be  the  set 
of  distinct  attribute  names  listed  in  the  WHERE  clause.  In 
case— Q  updates  (e.g. ,  the  above  example) .  no  attribute  is 
listed  in  both  the  SET  and  WHERE  clauses  (i.e.,  S  O  W  =  0) . 
In   case— 1  updates ,   one  attribute  is  listed  in  both  clauses 

(i.e.  ,   cardi  nality(S  H  W)  =  1).  In  case— 2  updates ,  mul t i  pi e 
attributes       are  listed      in       both       clauses 

(i.e.  ,  cardi  nality(S^W)  >  1).  A  case— 1  modi  f  i  cati  on  of 
our  example  is  as  follows: 
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UPDATE 
SET 


WHERE 


COLOR   =   Yellow', 
WEIGHT  =  WEIGHT  +  5, 
CITY    =   Normandy' 
<P#  =  'P2' )  AND  (CITY 


=  ' Pari  s  ) 


Note,  CITY  is  in  both  S  and  W,  and  the  cardinality  of 
■■SOW)  is  i.  A  case-2  modification  of  our  original 
example  is  as  follows: 


UPDATE 
SET 


WHERE 


COLOR   =  'Yellow', 
WEIGHT  =  WEIGHT  +  5, 
CITY    =   Normandy' 
<P#  =  'P2'>  AND  (CITY  = 
AND  (COLOR  = 


Paris  ) 
'GREEN' ) 


Note,  CITY  and  COLOR  are  in  both  S  and  W,  and 
cardinal ity (S  n  W)  >  1.  The  SQL-to-ABDL  translations  of  the 
three  cases  of  multiple-attribute  update  are  described  in 
the  following  subsection. 

a.   The  translation  to  ABDL 

ABDL  does  not  provide  a  single-request  construct 
which  updates  more  than  one  attribute  in  a  record.  We  must 
translate  the  SQL  UPDATE  into  multiple  ABDL  UPDATES.  Case-Q 
SQL  UPDATE  queries  can  be  translated  directly  to  multiple 
ABDL  UPDATE  requests.  The  order  in  which  these  requests  are 
processed    is    immaterial.      The   case— 0   example    above 
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translates  to  the  -following  three  independent  ABDL  UPDATE 
requests: 

UPDATE  ((FILE  =  P)  A       (P#  =  P2) )   (COLOR  =  Yellow) 
UPDATE  ((FILE  =  P)  A   (P#  =  P2) )   (WEIGHT  =  WEIGHT  +  5) 
UPDATE  ((FILE  =  P)  A   (P#  =  P2) )   (CITY  =  Normandy) 

Our  case— 1  example  translates  to  the  same  three 
UPDATE  requests,  however,  the  presence  of  the  CITY  attribute 
in  both  the  WHERE  and  SET  clauses  effects  the  structure  o-f 
the  translation.  The  order  o-f  request  processing  now 
becomes  important.  For  example,  i -f  CITY  is  updated  -first, 
the  condition  ( (P#  =  ' P2 ' )  AND  (CITY  =  Paris'))  is  no 
longer  satisfied  when  a  subsequent  attempt  is  made  to 
process  the  COLOR  and  WEIGHT  UPDATE  requests.  ABDL  provides 
a  construct  called  a  Transact! on  which  specifies  the  order 
in  which  a  series  o-f  requests  must  be  processed.  Therefore, 
the  case— 1  translation  becomes 

BEGIN  Transaction 

UPDATE  ((FILE  =  P)  A   (P#  =  P2> )   (COLOR  =  Yellow) 
UPDATE  ( (FILE  =  P)  A   (P#  =  P2))   (WEIGHT  =  WEIGHT  +  5) 
UPDATE  ((FILE  =  P)  A   (P#  =  P2) )   (CITY  =  Normandy) 

END  Transaction 

Requests  within  a  transaction  Are  processed  in  the  same 
order  as  they  are  specified.  Therefore,  we  can  obtain  a 
correct  result. 
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The  case-2  example  also  translates  to  a  series 
ot  three  ABDL  requests.  However,  the  translation  is  more 
complex.  In  this  case,  multiple  attributes  specified  in  the 
WHERE  clause  are  also  listed  in  the  SET  clause.  When  the 
first  of  these  attributes  is  updated,  all  subsequent 
attempts  to  update  the  remaining  attributes  will  fail. 
Since  the  WHERE  condition  is  no  longer  satisfiabie,  the 
record  can  not  be  found.  The  following  sequence  of  ABDL 
requests  accomplishes  the  requested  update.  (Note  that  the 
ABDL  UPDATE  construct  is  not  used). 


RETRIEVE  ((FILE  =  P)  A   (P#  =  P2>>  <P# , PNAME , COLOR , WE IGHT , 

CITY> 

DELETE  ((FILE  =  P)  A   (P#  =  P2)  A   (PNAME  =  Bolt)  A 
(COLOR  =  Green)  A   (WEIGHT  =  17)  A 
(CITY  =  Paris) ) 

INSERT  (<FILE  =  P>,<P#  =  P2>,< PNAME  =  Bolt>, 

<COLOR  =  Yellow>,<WEIGHT  =  22>,<CITY  =  Normandy >) 


b.   A  proposed  Software  Structure 

In  order  to  implement  multiple-attribute 
updates,  we  must  augment  the  functionality  of  the  software 
structure  (SQLI)  which  we  have  developed  in  Chapter  VI.  We 
specify  an  additional  parameter,  Request  Type,  to  be 
returned  by  SQLT.  When  the  value  of  RequestType  is 
' CaseO_update ' ,  the  subroutine  CaseO_update  is  called.  In 
this  case,  the  multiple  ABDL  RETRIEVE  requests  are  simply 
removed  from  Request_Stack  and  forwarded  to  MDBS  for 
processing.    As  previously  stated,   the  order  of  processing 
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does  not  e-f-fect  the  result.  When  all  updates  are  complete, 
the  user  is  so  in-formed.  When  the  value  o-f  Request _Type  is 
' Casel_update ' ,  the  subroutine,  Casel  update  is  called. 
When  the  value  o-f  RequestType  is  ' Case2_update ' , the 
subroutine,  Case2  update  is  called.  The  Casel_update  and 
Case2_update  subroutines  Are  presented  in  Figures  19  and  20, 
respect i  vel y . 

Subrouti  ne  Casel _update (Request_Stack , Resul t _Set ) 

/*  Transact  i  on_Request :  */ 

/*    is  a  template  with  the  Reserved  word  BOT  */ 

/*    -followed  by  multiple  blank  lines  (to  be  used  */ 

/*    by  the  series  of  requests)  and  the  Reserved  */ 

/*    word  EOT.  */ 

while  NOT  EMPTY (Request _Stack )  do 
Pop (Request _Stack ) 

Fill  in  blank  lines  of  Transact i onRequest  with 
requests  from  Request_Stack 
end  wh i 1 e 

Send (Transact i  on_Request ) 

Receive  (Resul  t_Set)  /-*  Resul  t_Set  returned  to     */ 

/*  calling  routine 


-*/ 


end  Casel_update 

Figure  19.   Subroutine  Casel_L)pdate 

The  Casel_Update  subroutine  builds  a  transaction 
o-f-  update  requests  for  MDBS  processing.  The  subroutine  is 
provided  the  parameter  RequestStack  which  contains  multiple 
UPDATE  requests  stacked  such  that  the  request  on  the  bottom 
of   the   stack  is  the  request  which  must  be  processed   last. 
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Subroutine  CaselJJpdate  sends  the  request  transaction  to 
MDBS,  Receives  the  ResuIt_Set,  and  returns  the  Result  Set  to 
the  calling  routine. 

Subrout i  ne  Case2_update (Request _Stack , Resul tSet ) 

/*  Insert_Templ ate:  */ 

/*    is  the  INSERT  request  with  values  for  the  */ 

/*    attributes— to— be— updated  and  blanks  -for  the  */ 

/*    attributes  whose  values  ^re    obtained  by  the  */" 

/*  RETRIEVE  request.  */ 

Send (Pop (Request _Stack ) )  /*  RETRIEVE  request  */ 
Recei  ve (Resul t_Set ) 

Send (Pop (Request_Stack) )          /*  DELETE  the  record  */ 

Recei ve (Resul t_Set )                /*  deletion  is  complete  */ 

Whi  1  e   there  ^re    records  to  update   do 

Insert_Templ ate  < —  /*  fill  in  blanks  with  retrieved  */ 

/*  attribute  values  -*/ 

Insert_Request  < —   /*•  form  the  INSERT  request  from  ■*/ 

/*  the  record  and  Insert_Templ ate  */ 

Send ( Insert_Request ) 
end  whi 1 e 

Recei ve (Resul t_Set)                /*  INSERT  is  complete  */ 

end  Case2_update 

Figure  20.   Subroutine  Case2_update 

The  Case2_Update  subroutine  controls  the 
execution  of  the  RETRIEVE-DELETE-INSERT  series  of  requests. 
The  RETRIEVE  obtains  a  copy  of  the  appropriate  record (s>. 
The  DELETE  deletes  the  original  record (s)  in  the  database. 
The  INSERT  re— inserts  the  record (s)  with  all  the  modified 
attribute  values. 

2.   Retr i  evi  nq  Qual i  f  i  ed  Groups 

Both    SQL   and   ABDL   provide   an   option    whereby 
retrieved   attributes  may  be  grouped.    For  example,   if   we 
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wish  to  obtain  the  part  number  and  the  total  quantity  -for 
each  part  supplied,  we  may  utilize  the  -following  SELECT 
construct : 

SELECT   P#,SUM(QTY) 
FROM     SP 
GROUP    BY  P# 


The  result  relation  is: 


p# 

-  — 

PI 

600 

P2 

1000 

P3 

400 

P4 

500 

P5 

500 

P6 

100 

Note  that  "...each  expression  in  the  SELECT  clause  must  be 
si  nql  e-val  ued  -for  each  group;  that  is,  it  can  be  either  the 
GR0UP_BY  -field  itself,  or  a  function  such  as  SUM  that 
operates  on  all  values  of  a  given  field  within  a  group  and 
reduces  those  values  to  a  single  value."  CRef.  9D 

The  above  SQL  operation  is  directly  supported  bv  the 
software  structure  of  Chapter  VI.  Using  the  SELECT— to— 
RETRIEVE  mapping  which  we  have  described  in  Chapter  III,  the 
equivalent  ABDL  construct  is: 

RETRIEVE  (FILE  =  SPXPtt  ,  SUM  (QTY )  >  BY  P# 

SQL  provides  a  further  option  for  use  with  grouped 
attributes.  Once  the  rows  of  a  table  are  grouped  by  a 
selected   attribute,    groups   not   satisfying   a   specified 
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condition  can  be  eliminated  through  the  use  o-f  the  HAVING 
operator.  The  -following  comprehensive  example  clarifies  the 
use  of  the  'GROUP  BY  with  HAVING'  option.  If  we  wish  to 
obtain  the  part  number  and  the  maximum  quantity  of  the  part 
supplied  for  all  parts  such  that  the  total  quantity  supplied 
is  greater  than  300  (excluding  from  the  total  all  shipments 
for  which  the  quantity  is  less  than  or  equal  to  200) ,  we  may 
use  the  following  query: 

SELECT  P#, MAX (QTY) 

FROM  SP 

WHERE  QTY  >  200 

GROUP  BY  P# 

HAVING  SUM (QTY)  >  300 


We  can  imagine  the  result  relation 


p# 

——^^^— 

PI 

P2 
P3 

P5 

300 
400 
400 
400 

being  formed  as  follows.  A  copy  is  made  of  table  SP  (FROM). 
The  rows  not  satisfying  "QTY  >  200"  are  eliminated  (WHERE). 
The  remaining  rows  are  then  grouped  by  P#  (GROUP  BY).  The 
newly  formed  groups  are  checked  against  the  predicate 
"SUM(QTY)  >  300".  Those  not  satisfying  the  condition  are 
eliminated  (HAVING).  Finally,  part  numbers  and  maximum 
quantities  are    extracted  from  the  remaining  groups  (SELECT). 
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a.   The  Translation  to  ABDL 

As  previously  discussed,  ABDL  provides  a 
construct  f or  the  retrieval  of  data  which  is  grouped  by  a 
selected  attribute.  In  the  comprehensive  SQL  example  above, 
the  use  of  the  HAVING  operator  specifies  a  further 
qualification  on  the  groups.  In  this  example,  the  groups 
whose  total  quantity  supplied  is  less  than  or  equal  to  300 
are  to  be  eliminated.  ABDL  does  not  provide  a  facility  for 
checking  this  group  condition.  This  condition  must  be 
checked  in  the  interface.  The  SQL  query  is  translated  to 
the  ABDL  request 


RETRIEVE  ((FILE  =  SP)  A   (QTY  >  200) )  <P# , MAX (QTY) , SUM (QTY) > 

BY  P# 


which  we  imagine  returns  the  following  table: 


p# 

MAX (QTY) 

SUM (QTY) 

PI 

300 

600 

P2 

400 

400 

P3 

400 

400 

P4 

300 

300 

P5 

t_  . 

400 

400 

Software  in  the  interface  then  checks  the  HAVING  condition 
"SUM (QTY)  >  300".  This  eliminates  the  grouping  for  part  P4. 
The  remaining  part  numbers  and  maximum  quantities  are 
returned  to  the  user. 
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b.   A  Proposed  Software  Structure 

When  SQLT  returns  the  value,  ' Group_by_havi ng 
-for  the  parameter,  Request_Type ,  we  assume  that  the  HAVING 
condition  is  also  made  available  to  the  Sroup-By-Havinq 
subroutine.  (We  make  a  similar  assumption  for  other 
Request _Types ) .  The  subroutine  sends  the  request,  receives 
the  result  set,  checks  the  HAVING  condition,  and  returns- 
only  those  tuples  satisfying  the  having  condition  to  the 
user.   Figure  21  depicts  this  operation. 


Subrouti ne  Group-By— Havi  ng (Request_Stack , HAVING_condi  t i  on , 

Result_Set) 
Send (Pop (Request_Stack ) 
Recei  ve (Resul t_Set ) 
Eliminate  groups  not  satisfying  HAVING  condition 

end  Group_By_Havi ng 

Figure  21.   Subroutine  Group_By_Havi ng 


3.   Retrievi  ng  Computed  Val ues 

The  concept  of  retrieving  computed  values  is  simple, 
yet  it  typifies  the  important  options  that  database 
management  system  designers  a.re  providing  in  order  to  ensure 
user  — f r i endl i ness  and  user— flexibility.  This  option  supports 
the  inclusion  of  arithmetic  expressions  involving  fields  as 
well  as  simple  field-names.  For  example,  the  user  should  be 
able  to  specify  uni ts— of —measure  for  numerical  results.  SQL 
supports  this  concept.  If  we  wish  to  obtain  the  part  number 
and   the   weight  of  the  part  in  grams  (given  in  table   P   in 
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pounds) ,  we  may  use  the  following  query: 

SELECT  P#, WEIGHT  *  454 
FROM    P 


The  result  relation  is; 


p# 

PI 

5448 

P2 

7718 

P3 

7718 

P4 

6356 

P5 

5448 

P6 

8626 

a.  The  Translation  to  ABDL 

In  this  translation,  the  ABDL  request  retrieves 
the  indicated  attributes  leaving  any  computation  to  be 
accomplished  in  the  interface.  For  the  example  above,  the 
ABDL  translation  is 

RETRIEVE  (FILE=  P)  < P#, WEIGHT > 

The  specified  arithmetic  operation  is  performed  by  interface 
software  on  the  retrieved  values  for  WEIGHT  (i.e.,  WEIGHT  * 
454)  prior  to  returning  the  final  result  relation  to  the 
user.  The  software  required  is  a  simple  interpreter  for 
evaluating  arithmetic  expressions. 

b.  A  Proposed  Software  Structure 

An  Expressi on_Eval uator  subroutine  can  be  used 
to  accomplish  the  arithmetic  operations  specified  in  the  SOL 
query.  The  subroutine  simply  utilizes  the  appropriate 
function  (e.g.,   Mul t , Add , Sub , Di v)  to  perform  the  operation. 
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4.   Provi  ding  Format  Opt i  ons 

Often,  the  i  n-f  ormat  i  on  retrieved  from  a  database  is 
intended  for  use  in  published  reports.  The  availability  of 
formatting  options  can  make  generating  these  reports 
simpler.  For  example,  while  it  is  prudent  to  save  disk 
space  by  storing  the  names  of  suppliers  as  values  for  an 
attribute-name  such  as  SNAME ,  an  end— user  unfamiliar  with 
the  database  is  psychologically  more  comfortable  with  a 
column  heading  such  as  SUPPLIERS.  In  SQL  queries,  the 
desired  format  is  indicated  in  the  SELECT  clause.  For 
example,  if  we  wish  to  obtain  the  names  of  all  suppliers,  we 
may  use  the  following  query: 

SELECT   SNAME  SUPPLIERS 
FROM     S 


The  result  relation  is: 


SUPPLIERS 


Smi  th 
Jones 
Blake 
Clark 
Adams 


Note   that  the  column  heading  is  SUPPLIERS  rather   than   the 
field  name,  SNAME. 

a.   The  Translation  to  ABDL 

This  translation  is  similar  to  that  presented  in 
Subsection  2  above.  Information,  returned  from  MDBS,  is 
modified  by  the  interface  software.  The  SQL  SELECT  query  is' 
translated  to  the  ABDL  request 


RETRIEVE  (FILE  =  S)  <SNAME> 

The  results  of  this  request  are  modified  by  the  SQL 
interface  (SQLI)  prior  to  returning  the  -final  result 
relation  to  the  user.  In  this  case,  the  column  heading, 
SNAME,  is  changed  to  the  new  heading,  SURRLIERS. 

b.   A  Proposed  Software  Structure 

Format   options   can  be  provided  in  the   Display 
subroutine.   Any  change  in  the  -form  o-f  the  table  heading  can 
be  passed  at  the  time  of  the  call  to  Display. 
5.   The  Retrieval  with  Ordering  (SORT) 

Generally,  the  result  of  a  SELECT  operation  is  not 
guaranteed  to  be  in  any  particular  order.  Ordering  (SORT)  is 
normally  not  accomplished  in  SQL  queries  unless  specifically 
requested  by  the  user.  This  operation  may  be  costly,  and 
the  additional  expense  is  often  unwarranted.  In  SQL,  the 
user  may  specify  ordering  through  the  use  of  the  ORDER  BY 
operator.  As  an  example,  if  we  wish  to  obtain  supplier- 
numbers  for  all  suppliers  providing  shipments,  such  that  the 
result  is  ordered  by  suppl 1 er— number ,  we  may  use  the 
following  query: 

SELECT   UNIQUE  S# 
FROM     SP 
ORDER    BY  S# 
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The  result  relation 


a.  The  Translation  to  ABDL 

In  the  translation  o-f  the  above  SQL  query,  we 
assume  an  ordering  capability  within  MDBS.  The  development 
o-f  this  capability  is  the  goal  of  a  current  thesis  by  Muldur 
CRef  15:.   The  ABDL  request 

RETRIEVE  (FILE  =  SP)  <S#>  ORDER  BY  S# 

returns  all  supplier  numbers  (ordered  by  increasing  supplier 
numbers)   contained  in  the  SP  -file   (including   duplicates). 

b.  A  Proposed  Software  Structure 

We  assume  that  the  ordering  of  selected 
attributes  is  directly  supported  by  MDBS.  Therefore,  no 
augmentation  of  SQLI  is  required. 

6.   An_  El  imination  of  Dupl  icates  (PROJECTION) 

The  results  of  a  SELECT  operation  may  contain 
duplicates.  The  elimination  of  duplicates  (PROJECTION),  as 
in  the  case  of  retrieval  with  ordering  (SORT) ,  is  normally 
not    accomplished   in   SQL   queries    unless    specifically 
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requested.  Again,  the  cost  is  high  and  often  unwarranted. 
An  exception  to  this  rule  is  that  duplicate  rows  are 
automatically  eliminated  in  UNION  operations.  (UNION 
operations  are    described  in  Section  B>  . 

In  SQL,  the  elimination  o-f  duplicates  may  be 
specified  through  the  use  of  the  UNIQUE  operator.  As  an 
example,  if  we  wish  to  obtain  supplier-numbers  for  all 
suppliers  providing  shipments  such  that  no  suppl i er— number 
is  listed  more  than  once,  and  the  result  is  ordered  by 
suppl i er— number ,  we  may  use  the  following  query: 

SELECT   UNIQUE  S# 
FROM     SP 
ORDER    BY  S# 


The  result  relation  is 


S# 


SI 
S2 
S3 
S4 


This  example  is  a  modification  of  the  example  presented  in 
Subsection  5.  Note  that  duplicate  suppl i er— numbers  are 
el i  mi  nated . 

a.   The  Translation  to  ABDL 

The  ABDL  translation  for  the  above  SQL  query  is 
identical  to  the  translation  for  our  Subsection  5  example. 
Again,  the  ABDL  request 

RETRIEVE  (FILE  =  SP )  <S#>  ORDER  BY  S# 
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returns  ail  supplier-numbers  (ordered  by  increasing 
suppi  1  er—  numbers)  contained  in  the  SP  -File  (including 
duplicates).  Since  UNIQUE  is  speci-fied  in  the  SELECT  clause 
o-f  the  SQL  query,  SQLI  must  check  the  ordered  rows 
eliminating  duplicate  values  -for  the  S#  attribute  prior  to 
-forwarding  the  result  relation  to  the  user.  I-f  our  example 
is  modified  such  that  the  ORDER  BY  clause  is  omitted,  we  may 
facilitate  the  elimination  o-f  duplicates  by  "forcing"  a  SORT 
of  the  selected  attributes.  That  is,  the  ABDL  RETRIEVE 
request  is  written  to  include  an  ORDER  BY  specification, 
b.   A  Proposed  Software  Structure 

When  UNIQUE  is  specified  in  the  SQL  query,  the 
Result _Set  from  MDBS  is  passed  in  a  call  to  a 
Dupl 1 cate_El i mi nator  subroutine.  This  subroutine  scans  and 
compares  adjacent  members  of  an  ordered  ResultSet 
eliminating  duplicate  members.  We  assume  that  the 
Result_Set  is  always  ordered  prior  to  being  passed  to 
Dupl icate_El imi nator .  The  ordering  is  either  user-specified 
or  "forced"  in  the  SQLT  translation. 

B.   SELECTED  MULTIPLE-RELATION  OPERATIONS 

In  this  section,  we  discuss  two  additional  multiple- 
relation  operations  which  are  supported  by  SQL:  retrieval 
using  the  UNION  operator  and  retrieval  specifying  JOIN 
operations.  These  two  operations  and  the  nested  SELECT 
(described  in  Chapter  V) 'give  SQL  much  of  its  power  and 
flexibility.    The   availability   of  query  constructs   which 
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allow   access   to  related  data  in   multiple   tables   greatly 
enhances   the  ease  with  which  a  user  can  obtain  the   desired 
information   -from   the  database.    We  investigate  UNION   and 
JOIN  operations  in  the  following  subsections. 
1.   The  Retrieval  Using  UNION 

From  set  theory,  we  recall  that  the  UNION  of  sets  A 
and  B  (i.e.,  A  UNION  B)  is  the  set  of  all  objects  x  such 
that  x  is  a  member  of  A  or  x  is  a  member  of  B.  The  formal 
predicate  logic  definition  of  A  UNION  B  is: 

Vx  C  ( x   A )   V  ( x   B )  3 

In  SQL,  the  UNION  operator  is  used  in  a  query 
comprised  of  mul ti pi e— SELECT  constructs.  As  an  example,  if 
we  wish  to  obtain  numbers  for  parts  that  either  weigh  more 
than  16  pounds  or  are  currently  supplied  by  supplier  S2  (or 
both) ,  we  may  use  the  following  query: 

SELECT   P# 

FROM     P 

WHERE    WEIGHT  >  16 

UNION 

SELECT  P# 
FROM  SP 
WHERE    S#  =  'S2' 


lOO 


The  result  relation  is: 


P# 


P2 
P3 
P6 
PI 


From  the  sample  database  of  Chapter  I,  we  can  see  that  parts 
P2,  P3,  and  P6  weigh  more  than  16  pounds  (x  £|A).  Part  PI 
weighs  less  than  16  pounds,  however,  PI  is  currently 
supplied  by  supplier  S2  (x  CB).  Part  P2  weighs  more  than  16 
pounds  and  is  supplied  by  supplier  S2  ( (x  ^ A)  A  (x  £  B) ) . 
Note  that  duplicate  rows  are  eliminated  from  the  result  of  a 
UNION  operation. 

a.  The  Translation  to  ABDL 

In  the  SQL  query  above,  each  SELECT  construct 
translates  into  an  equivalent  ABDL  RETRIEVE  request.  In 
this  example,  the  two  ABDL  requests 

RETRIEVE  (FILE  =  P)  A   (WEIGHT  >  16)  <P#>  ORDER  BY  P# 
RETRIEVE  (FILE  =  SP)  A   (S#  =  S2>  <P#>  ORDER  BY  P# 

are       processed   concurrently.  The  results  are    combined   in 

SQLI ,  where  duplicate  rows  are  eliminated.  The  remaining 
rows  are    forwarded  to  the  user. 

b.  A  Proposed  Software  Structure 

When  the  value  of  Request _Type  is  UNION,  the 
translation  and  processing  are  as  follows.  An  MDBS  SORT  is 
specified  in  the  ABDL  translation.  A  subroutine  called 
UNION   pops  all  ABDL  RETRIEVE  requests  off  of   Request_Stack 
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and  -forwards  them  to  MDBS  -for  concurrent  processing.  The 
ordered  result  sets  are  merged  (through  the  use  o-f  a 
standard  merge  -function)  ,  and  then  passed  to 
Dupl i cate_El i mi nator .  Finally,  the  uniquely  selected 
results  o-f  the  UNION  operation  are  returned  to  SQL  I  -for 
display  to  the  user.  Subroutine  UNION  is  presented  in 
Figure  22. 

Subroutine  UNION (Request_Stack , Resul  t_Set > 

while  NOT  EMPTY (Request_Stack )  do 

Send (Pop (Request_Stack ) 
end  whi 1 e 

Recei  ve (Resul t_Set 1 ) 
Recei  ve (Resul t_Set2) 
Merge (Resul t_Set 1 , Resul t_Set2) 
CALL  Dupl i  cate_El i  mi  nator (Resul t_Set ) 

end  UNION 

Figure  22.   Subroutine  UNION 

2.   The  Retr i  eval  Speci  f yi nq  Joi  n  Qperat i  ons 

Join  operations  are  characteristic  o-f  data  languages 
intended  for  use  with  relational  databases.  SQL  provides 
the  capability  to  specify  implicit  join,  equality  join,  and 
inequality  join  operations.  In  an  i  mpi  i  ci  t  join,  attribute- 
values  in  multiple  tables  are  compared,  however,  the  values 
returned  to  the  user  are  taken  -from  only  one  table. 
Implicit  joins  can  be  -formed  through  the  use  o-f  the  nested 
SQL  SELECT  constructs  which  we  have  described  in  Chapter  V. 
In  the  nested  SELECT,   multiple  tables  are    accessed  and   the 
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values  o-f  selected  attributes  are  compared.  We  note  that 
only  values  -from  the  outermost  SELECT  a.re  returned  in  the 
■final  result  set.  This  operation  results  in  the  -formation 
o-f  an  implicit  join. 

Equal  i  ty  join  and  i  n  equal  i  ty  join  operations  airs 
specified  by  referencing  multiple  tables  in  a  single  SELECT 
query.  As  an  example  o-f  an  equality  join,  i  -f  -for  each  part 
supplied  we  wish  to  obtain  part  numbers  and  names  of  all 
cities  supplying  the  part,  we  may  use  the  -following  query: 

SELECT   UNIQUE   P#,CITY 

FROM     SP,S 

WHERE    SP.S#  =  S.S# 


The  result  relation  is: 


p# 

CITY 

PI 

London 

PI 

Pari  s 

P2 

London 

P2 

Pari  s 

P3 

London 

P4 

London 

P5 

London 

P6 

London 

Note  that  table— names  may  be  used  as  qualifiers  in  the 
SELECT  and  WHERE  clauses  in  order  to  resolve  ambiguities  or 
to  ensure  clarity.  For  example,  the  SELECT  clause  mav  be 
equivalently  written 

SELECT   UNIQUE   SP.P#,S.CITY 
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Although  there  are  optimization  techniques  which 
-facilitate  a  more  e-f-ficient  implementation,  we  can  visualize 
the  join  operation  as  -follows.  First  the  Cartesian  product 
o-f  SP  and  S  is  -formed.  Then,  rows  not  satisfying  the 
condition  SP.S#  =  S.S#  are  eliminated.  Next,  columns  P#  and 
CITY  are  projected  -from  the  remaining  rows.  Finally,  since 
the  operator  UNIQUE  is  used,  all  duplicate  rows  are  removed 
he-fore  the  result  relation  is  returned  to  the  user.  (For  an 
indepth  discussion  of  the  efficiency  and  optimization 
considerations  of  implementing  join  operations,  the  reader 
is  referred  to  Demur jian  CRef.  ID). 

a.   The  Translation  to  ABDL 

The  attri bute— based  data  language,  as 
implemented  in  MDBS,  does  not  provide  a  join  capability. 
Muldur  CRef .  15D  is  currently  investigating  the  practicality 
of  incorporating  join  operations  within  MDBS.  If  we  assume 
that  the  functionality  of  MDBS  is  augmented  to  support  the 
equality  join  and  inequality  join  operations,  we  might  use 
the  following  translation  for  the  equality  join  (as 
discussed  in  Demur jian  CRef.  ID).  The  general  form  of  a 
simple,  two— way  equality  join  expressed  in  the  syntax  of  SQL 
i  s 

SELECT   sel_expr_list 

FROM     rel at i on_namel ,  rel at i on_name2 

WHERE    rel at i on_namel . attri bute  =  rel at i on_name2. attri bute 
AND  qualification 
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The  general  -form  of  the  ABDL  translation  is 

RETRIEVE     (attribute_list_l )   (query_l) 
CONNECT  ON   (attr i bute_l ,  attribute_2) 

<attribute_list_2>   (query_2> 

The  sel_expr_l  ist  of  the  SQL  SELECT  is  divided  into  a  target 
list  consisting  of  attributes  from  rel ati on_namei  and  a 
target  list  consisting  of  attributes  from  rel at i on_name2 . 
The  qualification  of  the  SQL  SELECT  is  likewise  partitioned. 
The  attributes  named  in  the  equality  predicate  become  the 
object  of  the  CONNECT  ON  clause  in  the  ABDL  request. 
Following  this  general  form,  the  translation  for  the 
equality  join  example  of  the  preceding  subsection  is 

RETRIEVE   <  (S#,P#)   (FILE  =  SP)  > 
CONNECT  ON  (SP.S#,  S.S#) 

<  (S#,CITY)   (FILE  =  S)  > 

b.   A  Proposed  Software  Structure 

As  stated  previously,  we  assume  a  join 
capability  for  MDBS.  Therefore,  no  augmentation  of  SQLI  is 
r equi  red . 

C.   THE  MODIFIED  SOFTWARE  STRUCTURE  OF  THE  SQL  INTERFACE 

In  this  section,  we  present  the  modified  software 
structure  of  SQLI.  We  modify  the  structure  which  we  have 
presented  in  Chapter  VI  in  order  to  facilitate  the 
implementation   of   the  additional  operations   described   in 
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this  chapter.  The  modified  version  of  the  top-ievel 
process,  SQLI,  is  shown  in  Figure  23.  Note,  we  have 
simplified  this  algorithm  through  the  use  of  the 
Request_Control  subroutine.  The  functionality  of  this 
subroutine  is  presented  in  Figure  24.  The  purpose  of 
Request_Control  is  to  provide  overall  control  of  request 
processing  for  the  interface.  A  high— level  view  of  the 
modified  software  structure  is  shown  in  Figure  25,  and  the 
relationship  between  Subroutine  Request_Control  and  its 
subordinate  group  of  subroutines  is  depicted  in  Figure  26. 


ALGORITHM  SQLI  (Modified) 

Repeat 

CALL  Get _SQL_Query (Query) 

CALL  SQLT (Query ,Request_Stack , N , Errors , Request_Type , 

Format_Opt i on , Ar i  th_Expr ) 
if_  N  =  0  then  /*  Syntax  Errors  */ 

CALL  Display (Query) 
CALL  Di spl ay (Errors) 
el  se 
CALL  Request_Control (Request _Stack , N , Request _Type , 

Ar i  th_Expr , Resul t_Set ) 
CALL  Display (Resul t_Set , For mat _Opti on ) 
end  i  f 
End_of  _sessi  on? 
unt i 1  end_of _sessi on 
end  ALGORITHM  SQLI  (Modified) 

Figure  23.   ALGORITHM  SQLI  (Modified) 
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Subrout i ne  Request _Control ( Request _S tack , N, Request  Type , 

Ar  i  th_Expr , Resui  t_Set ) 
CASE  Request_Type  OF 

CaseO_Update:   CALL  CaseO_Update (Request_Stack , Resui t_Set ) ; 

Casel_Update:   CALL  CaseiJJpdate (Request_Stack , Resui t_Set ) ; 

Case2_Update:   CALL  Case2_Update (Request _Stack , Resui t  Set ) ; 

Group_Havi ng :   CALL  Group_Havi ng (Request_Stack , 

Condi  t i  on , Resui t_Set ) ; 

UNION:  CALL  UNION (Request_Stack , Resui t_Set ) ; 

Others:  i-f  N  =  1  then 

CALL  Qne_Request (Request_Stack , Resui t  Set ) 
/*  -for  simple,  di  recti  y— supported  */ 
/*  single  request  */ 

el  se 

CALL  N_Level_Select (Request_Stack , 

N, Resui t_Set) 
end  i  -f 

END  CASE 

Figure  24.   Subroutine  Request_Contr ol 
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SQL  I 

Get_SQL 
Query 

SQLT 

Request 
Control 

Di spl ay 

Figure  25.   A  High-Level  View  of  the  Software  Structure 
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Figure  26.   Request_Control  and  its  Subroutines 


109 


VIII-   CONCLUDING  REMARKS 

In  this  thesis,  we  have  concentrated  on  the  language 
inter-face  aspects  of  using  an  attribute-based  database 
system,  MDBS,  as  a  kernel  -for  the  support  of  the  relational 
data  model  and  the  relational  query  language,  SDL.  A 
related  thesis  by  Weishar  CRef .  163  provides  the  design  and 
analysis  of  an  interface  for  the  hierarchical  model  and  the 
hierarchical  data  language,  DL/ I .  This  work  is  part  of 
ongoing  research  being  conducted  by  the  Laboratory  for 
Database  Systems  Research  under  the  direction  of  Dr.  David 
K,  Hsiao.  As  stated  in  CRef.  ID,  the  goal  of  this  phase  o-f 
the  laboratory's  research  "...is  to  provide  increased 
utility  in  database  computers.  A  centralized  repository  of 
data  is  made  available  to  multiple,  dissimilar  hosts. 
Furthermore,  the  database  is  also  made  available  to 
transactions  written  in  multiple,  dissimilar  data 
1 anguages. " 

The  rapid  evolution  of  database  technology  has  provided 
the  motivation  for  this  research.  Commercial  database 
management  systems  have  only  been  available  since  the 
1960's.  Today,  organizations  of  ail  types  sre  critically 
dependent  on  the  operation  of  these  systems.  This 
dependency   comes  from  the  need  to  centrally   control   large 
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quantities  of  operational  data.  The  information  must  be 
accurate  and  readily  accessible  by  relatively  inexperienced 
end-users . 

There  are  three  generally  known  approaches  to  the  design 
o-f  database  systems.  These  aire  the  network,  hierarchical, 
relational  approaches.  An  organization  normally  chooses  a 
commercial  system  based  on  one  o-f  these  models.  The 
database  must  be  created  and  operator  and  user  personnel 
must  be  trained.  Because  o-f  the  re— progr  ammi  ng  and  re- 
training effort  (and  money)  required,  an  organization  is 
unlikely  to  change  to  a  system  based  on  one  o-f  the  other 
model s. 

We  have  discussed  an  alternative  to  the  development  of 
separate  stand— alone  systems  -for  specific  data  models.  In 
this  proposal,  the  three  generally  known  models  and  their 
model— based  data  languages  aire  supported  by  the  attribute- 
based  data  model  and  data  language.  We  have  shown  (in  the 
relational  case)  how  a  software  interface  can  be  built  for 
such  support. 

Specific  contributions  of  this  thesis  include  extremely 
thorough  explanations  of  SQL  operations  such  as:  set- 
membership,  nested  retrievals,  retrieval  of  grouped 
attributes,  join  operations,  retrieval  of  computed  values, 
providing  format  options,  retrieval  using  UNION,  updating 
multiple  fields,  retrieval  with  ordering,  and  elimination  of 
duplicates.    We  have  extended  the  work  of  Macy  CRef.   S]  by 
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showing  that  many  of  the  SQL  constructs  -for  the  above 
operations  are  directly  supportable  by  ABDL  and  MDBS. 
Others  can  be  translated  into  a  series  o-f  the  primary  and 
aggregate  operations  o-f  the  attribute-based  system.  In  all 
cases,  SQL— to— ABDL  translations  are  provided.  We  have  also 
proposed  a  software  structure  to  facilitate  the  future 
implementation  of  the  SQL  interface. 

A  major  design  goal  has  been  to  design  a  SQL  interface 
to  MDBS  without  requiring  that  changes  be  made  to  the  MDBS 
system.  We  have  shown  that  the  complete  interface  can  be 
implemented  on  a  host  computer.  All  translations  are 
accomplished  in  the  SQL  interface.  MDBS  continues  to 
receive  and  process  requests  written  in  the  syntax  of  ABDL. 
We  have  also  shown  that  the  interface  can  be  designed  to 
utilize  existing  ABDL  constructs  (either  one  or  a  series  of 
ABDL  requests).  No  changes  to  the  ABDL  syntax  are  required. 
We  also  have  not  proposed  any  changes  to  the  syntax  of  SQL. 
We  have  designed  the  interface  to  be  transparent  to  the  SQL 
user.  The  intention  is  that  a  trained  SQL  user  need  know 
nothing  of  the  existence  of  the  interface  or  of  MDBS.  The 
user  can  log  in  at  a  system  terminal,  input  a  SQL  query,  and 
obtain  result  data  in  a  relational  format. 

In  retrospect,  our  unconventional  bottom— up  approach  to 
design  seems  entirely  appropriate.  We  have  built  upon  the 
basic  subset  of  SQL— to— ABDL  mappings  provided  by  Macy  CRef. 
83,   making   additions  to  the  set  as  selected  SQL  operations 
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have  been  incorporated  into  the  inter-face.  As  our 
investigation  begins  in  Chapter  IV,  the  -form  of  the 
inter-face  software  structure  is  not  clear.  When  the  nested 
SQL  SELECT  is  described  in  Chapter  V,  the  requirements  for 
the  structure  begin  to  solidify.  We  became  aware  that  an 
iterative  structure  is  needed  to  control  the  processing  of 
series  of  ABDL  requests.  As  the  algorithm,  SQL  I ,  is 
completed  in  Chapter  VI,  it  is  clear  that  we  have  developed 
the  overall  software  structure  for  the  SQL  interface.  The 
functionality  of  the  structure  is  enhanced  as  additional  SQL 
operations  a.re  selected.  However,  the  general  structure 
remains  intact. 

As  an  alternative  to  implementing  the  SQL  (network  and 
hierarchical,  as  well)  interface  on  a  host  computer,  the 
interface  can  be  placed  inside  of  MDBS.  We  have  studied 
this  possibility,  and  recommend  against  such  an 
implementation.  A  major  design  goal  of  MDBS  is  to  minimize 
the  role  of  the  controller.  This  goal  can  not  be  attained 
if  the  controller  must  support  the  operation  of  resident 
relational,  network,  and  hierarchical  interfaces. 

We  have  shown  that  the  attribute-based  system  supports 
relational  database  applications.  We  have  provided  SQL-to— 
ABDL  translations  for  selected  database  operations,  and  we 
have  proposed  a  software  structure  to  facilitate 
implementation.  The  next  step  is  to  implement  the  interface 
on   a   host  computer.     In  order  to   finally   determine   the 
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overall  practicality  o-f  using  MDBS  as  a  kernel  database 
system,  we  must  also  implement  the  hierarchical  inter-face 
design  of  Weishar  CRe-f.  163.  Additionally,  an  inter-face  to 
support  the  network  model  must  be  designed  and  implemented. 
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APPENDIX  A:   FORMAL  SPECIFICATION  OF  THE  ATTRIBUTE-BASED 
DATA  LANGUAGE,  ABDL 


The   following  is  the  BNF  -for  the  attribute-based   data 

language   developed  by  Hsiao  and  Menon  CRefs.   4   and   10D- 

Square    brackets  C   1       are       used   to   indicate    optional 
constructs. 


Predi  cate 

attri bute 

attri bute_bei  ng_modi  f  i  ed 

base_attr i  bute 

val  ue 

Conjunct 

Query 

Stat 

list_el 

list 


Target_l i  st 
Attri bval _pair 
Hal f  _record 

Record 


attribute  rel _op  value 

char  str i  ng 

attribute 

attribute 

str i  ng 
!  number 
!  float 

(Predicate) 

!   (Conjunct  /   Predicate) 

Conjunct 
!  Query  /   Conjunct 

avg  :  max  :  min  :  sum  :  count 

Stat  (attribute) 

attri  bute 
1  ist_el 

1 ist  7  attri  bute 
list , list _el 

:=   (list) 

:=   < attri bute , val ue> 

:=   Attr ib_val _pai r 

!  Half_record,  Attr i bval _pai r 

:=   (Half  record) 
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Pointer  :=   number 

Modifier  :=   type— 0 

i  type— I 

I  type-II 

!  type-II I 

!  type-IV 

type— 0  :=   <attri bute_bei ng_modi f i ed  = 

val ue> 

type— I  :  =   <attri  bute-bei  ng_modi  -f  i  ed  = 

exprl > 

type— II  :=   <attri bute_bei ng_modi f i ed  = 

expr2> 

type— III  :=   <attri bute_bei ngmodi f i ed  = 

expr2  o-f  Query > 

type— IV  :=       <attri bute_bei ngmodi f i ed    = 

expr2    o-f    Pointer)- 

Request  :=   Insert  !  Delete  !  Update  ! 

Retri  eve 

Insert  :=   INSERT  Record 

Delete  :=   DELETE  Query 

Update  :=   UPDATE  Query  Modifier 

Retrieve  :=   RETRIEVE  Query  Targetlist 

[BY  attribute: 
[WITH  Pointer] 

uc-letter  :=   A  !  B  !  C  !  ...   !  Z 

string  :=   uc_letter 

!  string  uc_letter 

lc-letter  :=   a  !  b  !  c  !  !  z 

char  string  :=   uc_letter 

!  char_string  lc_letter 

digit  :=   0!1!2!3!4!5!6! 

7  !  8  !  9 

number  :=   digit 

!  digit  number 


116 


-float 
add  op 
mul t  op 
expr  1 

arith  terml 


=   number . number 


=   * 


ari th_terml 
!  exprl  add_op  arithterml 

ari  th_-f  actor  1 
!  arith_terml  mult  op 
arith  -factorl 


arith  -factorl 


attr i  bute_bei  ng_modi  1 1 ed 
!  number 


expr2 


arith  term2 


ari  th_term2 

!  expr2  addop  arith  term2 

ari th_f act or 2 
!  arith_term2  mult_op 
arith  factor? 


arith  -factor? 


baseattr i  bute 
!  number 
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